Great initiative, and sorry that I missed it. Thanks for pointing this thread out to me.
I have opinions, strong ones, but as often happens, who does the work gets to choose.
On variable naming and using #@ params: I’d do neither. Instead, I’d prefer light parsing of the code.
from ij import IJ # IJ is class for which we call getDeclaredFields and getDeclaredMethods behind the scenes.
imp = IJ.getImage() # we know that getImage returns an ImagePlus
imp. # autoexpand knows that to do
from ij import ImagePlus # is class for which we call getDeclaredFields and getDeclaredMethods behind the scenes.
from ij.process import ByteProcessor # idem
imp = ImagePlus("one", ByteProcessor(256, 256))
imp. # autoexpand knows what to do
In other words: my first approach to autoexpand would be to scan the script for import statements, load data from the classes found, and then use that as shown above.
The above would be already very useful, and it’s feasible, as it doesn’t try to do everything but already removes most of the pain.
To note that it’s feasible but it isn’t trivial: one has to parse code scopes to find out which of the many “imp” is meant. Which in python code is straightforward, given the use of white space, and it would be acceptable to “give up” when it’s too convoluted and not offer autocompletion then. The point here is to cater to the trivial case, which are the majority.
Another painful point is writing the imports themselves. So for that:
from ij import # here, autoexpand would list all classes in package ij
For the above to work, all it needs is the list of classes in all jar files in Fiji. Finding this out takes 4 seconds on my system, and once cached, it’s essentially instantaneous. See new class ClassUtil in the Script Editor repository.
Unlike examples 1 and 2, example 3 is trivial to implement.
In addition, consider this example as well:
imp = ImagePlus # here, autoexpand would suggest both expanding to class names starting with ImagePlus and auto-adding the import to it at the top of the file
Above, a choice among possible classes to auto-import would be offered, and upon acceptance the import would be added at the top.
It’s also trivial to implement, given the strong convention for upper case in the first letter of a class name. And for static methods, ditto: trivial to load. This helps with e.g. ImgLib2’s
Intervals, Converters, Views, RealViews, ImageJFunctions which appear in many scripts.
None of the above examples expand on declared variables, including classes and their methods defined in the python script itself. This could be added later, as these are far less of an issue: the script author just wrote them and knows them. A possibility would be to tokenize the whole script by words, then pattern-match on the last word-like string typed: would not be class-aware (would be more like a plain text editor autoexpand), but would do the job almost always. These could be colored differently in the autoexpand listing.
The key issue is really discovery of classes whose name one only vaguely remembers (e.g. was it
ShortArrayVolatile?) and to facilitate their auto-import (remembering the package
this.that.then.whoa.long.isn.t.it is even harder).
In other words, solving Examples 3 and 4 would already go a long way.
My 2 cents. I really would like to see the above happen. With my limited time available, it may take me a year, but I’m slowly crawling towards it. The
ClassUtil which was useful to fix the “Open Help for Class” in the Script Editor is my first step towards it.