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
To add to this: even before parsing script parameters for possible object auto-completion later in the script code, it would be awesome to have auto-completion for all aliases of Java classes currently registered with the ScriptService, such that the following would work:
an so on…
… and then auto-suggestion of style, label, value, choices, min, max when you type an opening parenthesis… (just dreaming)
Wow, I can’t believe I missed this thread and didn’t get a chance to vote! We work entirely in Groovy for scripting and this would be a game changer for us. A bunch of us here would use this on a daily basis. In fact, people often complain that scripting is much harder in Fiji because there is no auto-completion and this creates an extra barrier for new users to get started.
However, I do agree with @imagejan that a specific variable naming scheme is a bit cumbersome. That would seem to require a lot of additional training for people. If there is a way to implement this using the Script Parameters and aliases that would already be a huge help.
I mostly code in java in Eclipse so that is my frame of reference for how this could work. I guess the dynamic typing in scripting languages is a challenge for the implementation, but in groovy you can also statically declare variables. I wonder, could autocompletion then just show up if a variable has been statically typed and otherwise not? This seems least intrusive and tremendously powerful, but the same would not be possible in Python I guess where there is no static typing.
Fantastic suggestion and effort @haesleinhuepf. I hope this project can go somewhere. Please let me know if there is any way we can help here!
I would be super thrilled to have code completion. However, I think requiring a suffix like _imp would end up encouraging uglier scripts in the wild. I would like to find a solution that ideally is agnostic to naming, or else that encourages good naming.
@haesleinhuepf Any chance you have time this coming week to work on this for an afternoon with me? I would love to try implementing some ideas like what @imagejan suggested.
sure! I’m happy to join the hackathon. I’m afraid that good auto-completion will be hard to achieve without influencing variable naming - just because of the type-less nature of jython. But maybe there is a way and I just don’t see it Otherwise, let’s think about that:
IMHO, it is a de-facto standard that people call variables something like ...Imp but any improvement is welcome.
Who here in the forum has an opinion of how to encourage good variable naming?
If we do decide to use variable naming to hint at autocompletion, this could be fine. I’d suggest we model it after names used very commonly in the wild: imp for ImagePlus, rm for RoiManager, img for Img, and maybe in general fooBar for FooBar with adjusted camel case. I find suffixes like foo_imp much less nice (reminds me of Hungarian naming, which some substantial fraction of programmers hate). But I could probably be convinced, especially if we cannot find any other viable solution.
That said, I think @imagejan’s idea of keying off the script parameters is right on, because at least for script parameters, we also do have the types as a starting point. It will be much easier to start with those.
@haesleinhuepf I finally got the chance to test this out. This is very helpful. Thanks for linking the code.
I don’t have a great solution for the naming question beyond when I already posted. At the moment, I defined some names that were convenient. But already ij is really helpful.
Another question came up through. Is it possible to have javadoc show up? In the macro autocompletion I guess you pull the documentation directly from the web. Can you think of an easy way to do that with javadoc?
I’m pretty sure that there are libraries for parsing Java-doc. We could also think of automatically reading the javadoc online. However, at the moment this project is kind of stuck. We’re looking for volunteers how would be interested in investing time (See message above). If you’re interested and found a library which can parse javadoc, I’m happy to give you directions how to build it into the auto-completion. But keep in mind: python doesn’t play well with types, so it might be hard to guess the right type (and thus Java-class)