Language Server Protocol Service for script editor autocompletion

Thanks to the efforts of @haesleinhuepf we have wonderful autocompletion in the script editor for macros and now thanks to the work of @albertcardona we have autocompletion for Jython scripts, but we still don’t have any autocompletion for groovy or other languages (maybe there is a possibility for java but it is currently turned off ?). @haesleinhuepf made a post about this and there was some discussion

I was wondering if anyone considered implementing the Language Server Protocol in SciJava as a general solution for this problem. In this protocol a Language Server provides a range of services for a given programming/scripting language including autocompletion, parsing, hover, definition, etc… Clients only need to implement a Language Client interface and connect to the server to get all these features for a given language.

One nice aspect of this model is that the Language Client interface is language independent, so it only needs to be implemented once for a given script editor (client) and then the client can connect to Language Servers for any supported language. This protocol seems to be gaining momentum and is becoming the preferred implementation for many IDEs. One common java implementation of this protocol is provided from eclipse - GitHub - eclipse/lsp4j: A Java implementation of the language server protocol intended to be consumed by tools and language servers implemented in Java. and the key interfaces can be found here.

I also found a nice groovy language server implementation based on lsp4j - GitHub - prominic/groovy-language-server: A language server for Groovy with a groovyv3 branch consistent with the version in the scijava pom. This is just for groovy, but looking around I think there are Language Server implementations for many languages.

I was thinking we could create a new SciJava service that keeps track of LanguageServers and provides them to clients called something like LanguageServerProtocolService. Then new and different implementations of Language Servers could be added to the service to gain new features in the script editor or override old implementations with only a minimum amount of work.

I currently have the problem that I would like to provide autocompletion support for a javafx editor and would love to see it in the main swing script editor. Instead of writing it twice, I was thinking setting up this server could work for both clients.

I have been able to setup a minimal working implementation of the above proposal that provides autocompletion using the groovy language server above. At the moment, it is still a mess and was just for testing. I will keep working on it when I have time and push it to GitHub somewhere for more feedback.

For now I wanted to see if anyone else in the community considered this model/has input about the design. There are a lot of critical design questions. For example, usually only one client is allowed in this protocol, but I would prefer an implementation that supports multiple clients for one server - I think this is possible.

Thanks for reading and let me know if you have any comments or suggestions!


Hi Karl,

Not having looked at the question in depth, only to comment that the language service for autocompletion already is implemented as a language service. For Jython:

And for Java and Javascript, which are already implemented and, as far as I know, both work:

The issue is not with the framework for adding language autocompletion in a language-independent way; the issue is that nobody has yet committed the time to write one such service for languages other than the 3 above.




Hi Albert,

Thanks a lot for your response and the helpful links! I actually started implementing groovy support using the LanguageSupportService following your lead with Jython and the work done by @haesleinhuepf. Then I discovered the groovy-language-server that I linked and realized there was a very nice implementation of groovy support there better than what I would probably have time to write myself. The same is true for the other languages.

One option is to wrap the groovy-language-server inside a GroovyLanguageSupportPlugin similar to the others, but I was also hoping to use this feature for a javafx editor I had been working on that also runs in Fiji.

But LanguageSupportService looks like it would only work for RSyntaxTextArea and doesn’t implement all the features provided by the language server protocol. This is why I wrote the post.

I was thinking we could add an LSP scijava service for other languages as well as other editors in addition to the service we have now that is specific to RSyntaxTextArea.

I will look into the interface you linked again and consider if I could somehow also use it for my other editor.

Thanks a lot for the feedback @albertcardona !



1 Like