It looks like the entire fiji.scripting.completion package did not make it into the ImageJ2 version of the Script Editor. Johannes, is the port merely unfinished, or is there some other reason for that? Licensing issues? Or can we migrate the code from that package to fix this issue?

Yes, I confirm that the auto-completion "support" was completely scratched from the script editor. It never worked, and I decided at some stage that I cannot be held responsible for cleaning up a Google Summer of Code project for which I was neither student nor mentor (and for which I already did a lot, a really big lot more than was my due as administrator for the Fiji organization).

The auto-completion support was not really necessary for the "Add import" anyway. It's just that at some stage, the code to discover all available packages and classes needs to be reinstated. However, this requires a little care with regards to the separation of concern: Fiji's script editor was a pile of code that mixed GUI and function and Git support and a half-working auto-completion support and incomplete and inconsistent features that were available only for specific languages ("Edit>Add import", for example, is only available for Java! For no good reason, either). We can do much better than this! The auto-completion support, for example, is UI-agnostic. So it should not live in the same package as the script editor GUI. It is -- as the "Edit>Add import" command -- subject to language-specific code, so there needs to be a base interface in SciJava common (and either a new service or new API for the ScriptService), and the script languages need to implement said interfaces

Unfortunately, we still have a couple of issues to address before we can go to address power users' issues involving heavy script development. This issue is therefore not on my immediate radar, even if I assign it to myself.

In the meantime, everybody compelled to work on this is of course welcome to do so. Remember: Fiji is no longer a complaint-driven project, meaning that it is no longer enough to just complain and the work will be performed magically (it is actually not really magic when Mark, Curtis or I have do all the work...). Fiji is a collaboration-based project now.

Thanks, Johannes, for the clarification.
I never knew that the "Add import" feature was part of a planned auto-completion project. My bug report was not meant as a complaint, I just wanted to report the lost functionality as soon as I stumbled upon it, not knowing if it was intentional or just an oversight while migrating to the scijava framework. I understand that there are many more pressing issues.

While developers looking for auto-completion support will probably switch to a proper IDE anyways, I still think the "Add import..." feature was very useful for scripting users who might not have any knowledge of the detailed API structure, even might be even more useful if available for all scripting languages.

That said, I would be willing to contribute here if I find the time, but I would require some pointers how to proceed. Please excuse my absolute ignorance concerning the SciJava framework: for example, what needs to be done to migrate fiji.scripting.completion.ClassNames to SciJava?

Cheers,
Jan

> That said, I would be willing to contribute here if I find the time, but I would require some pointers how to proceed.

Gladly!

For what it is worth, let me point out that I find the collaboration between you and me in particular very rewarding.

> for example, what needs to be done to migrate fiji.scripting.completion.ClassNames to SciJava?

Well, the first idea would be to identify the concerns. The first one is that you want to enumerate (i.e. provide an Iterable of some sort) a map of package names to class names contained in that package. The classes should be discovered on the class path -- which we can do easily, we even have code for that already: https://github.com/scijava/scijava-common/blob/54a8a5574b68309ea3f16b178e772b677867d666/src/main/java/org/scijava/annotations/EclipseHelper.java#L140-L157

Granted, this code is a little bit different from what we need: first of all, it does not decouple the enumeration of the classes from their processing (but this could be easily done through a callback interface, i.e. by passing an object implementing a certain interface whose single callback method is executed on all found classes).

The code in the EclipseHelper also has code to detect whether the passed URLClassLoader is unlikely to be called from within Eclipse (because the purpose of the EclipseHelper is to compensate for Eclipse's non-standards-compliant failure to process annotations while compiling, but we do not need that for the class importer).

I would suggest to adjust and move that code into the org.scijava.utils.ClassUtils class, as a static method accepting a ClassLoader and a ClassNameVisitor (which is how I would call the callback interface).

Then I would suggest to add two methods to the org.scijava.script.ScriptService interface: getClassMap(), returning a (cached) map of package names to class names, and getPackagesForClass(), returning a (cached) map of class names to package names. Of course, the org.scijava.script.DefaultScriptService needs default implementations of both.

The TextEditor can then make use of those new methods.

See https://github.com/imagej/imagej-ui-swing/pull/67 for my first pass at a simple implementation using the Reflections 3rd party library.