assume there’s a chance to get auto-completion in Fijis script editor. However, it will only work if you change your way of naming variables. E.g. every ImagePlus must end with _imp. Would you like to use it?
apparently, about 30% of the people don’t like the idea so much. Furthermore, I have the feeling that the community of scripters using python and/or groovy in Fiji is kind of tiny. Thus, I’m not sure if it’s worth to invest much effort into making this auto-completion user-ready.
Just to get me right: I got a lot of positive feedback when I implemented auto-completion for Imagej macro. Thus, every minute spent was worth it a hundred times. I’d be happy to do a similar thing for python and groovy. However, while auto-completion is a game changer for life scientists who do macro coding in Fiji, it may be not be at all for Fiji python programmers who have much better tools for scripting like Pycharm, Intellij or Eclipse. Thus, I tried to ask: Better no auto-completion instead of not-so-great auto-completion?
I put the code for the auto-completion tool I’m using from time to time in Fiji on github and refactored it a bit for a more broad usage. The most important class lives here: ScriptingAutoCompleteProvider
I believe the tool might be especially of interest for ImageJ2 and Ops users who script things like this.:
But I honestly hardly write any scripts like that.
To make a long story short: If there is anybody who is willing to support me in pushing this project further, he is very welcome. I think we’re not too far away from a relatively good auto-completion for python and groovy but there is some way to go. And it might never be as good as in modern IDEs. Nevertheless, an additional creative mind might be helpful.
Even ifi have no time to suppport, I really like the idea of python scripting with code completion.
It is true that PyCharm is a great tool but it is also loaded with many thing you do not need when writing scripts in Fiji. And youdo not have to explain how to use PyCharrm to write and run fiji scripts. This is far from being straight foreward.
Thanks @haesleinhuepf for your work on this! Indeed, I think it would be awesome to have code completion for any script language (clearly Jython and Groovy being the most important ones).
I admit I was one of the (three) people voting for “If it’s OPT-OUT it’s fine”. Not because I wouldn’t like the idea, in contrary I’d probably be one of its most active users
The reason why I was a bit concerned is the high degree of hard-coded conventions: not only ip for ImageProcessor and imp for ImagePlus (I agree this even could be useful to enforce some degree of convention across the community), but also for less obvious things like roimanager., cur. and display. – among others…
Just to name a few things I’d do differently (and others might disagree and/or have even other ways of naming things):
I usually name a RoiManager parameter rm, not roimanager.
I use #@ parameters for all services and avoid ij.ops(), ij.command() etc.
When calling Ops from scripts (at least in Groovy) it’s usually much less painful to call e.g. ops.run("filter.gauss", ...) instead of ops.filter().gauss(...); your current implementation wouldn’t help in this case.
I wonder whether it would be possible to use the (language-agnostic) script pre-processing framework to provide dynamic auto-completion for script parameters, i.e. actually use the name you define in the script parameters and add auto-completion specific to those:
#@ OpService myOpService
#@ RoiManager rm
This could be parsed in real-time (maybe whenever new line is added, or every change…?) to then provide auto-completion specific for myOpService and rm.
I think opt-out would be sensible in your current implementation, just for unforeseen cases where the auto-completion disturbs the way some script developers work. Other than that, I think it’s a fantastic first implementation that is definitely better than no auto-completion, but could be replace by a better, more generic version in the (more or less distant) future.
indeed that sounds like a nice and implementable idea. In fact the auto-completion for Java (yes, this already exists but was commented out on the master branch until @ctruden reenabled it recently) supports parsing code to find out types of variables. I sent a pull-request to the developers of the editor to make something like this run. The problem is, that the original auto-completion would run through the classpath and index all classes in order to build the pulldown content. As this would take 100 years in ImageJ, I suggested a change. It might not be necessary for your suggestion, but it would help to make it even better