Community
Participate
Working Groups
I would like to use the language server IN ADDITION TO existing tooling in Eclipse. In my case I would like to implement a language server that adds features to Java source files, like adding additional content-assist entries, etc. It would be great if I could re-use the lsp4e for that case, so that lsp4e is not only applicable for the newly added generic editor, but also for other file types with existing editors.
That is a cool use case. I think that it's not possible to add the support to third-party editors in a generic way without their cooperation. An "non-generic" editor defines its SourceViewerConfiguration and specifies what classes implement support for the different functionality in a hard-coded way (usually). If there is a way to extend the configuration, it would be specific to that editor (or else there wouldn't have been a need for the generic editor). What might work (but then is an issue for the generic editor team) is to make it possible to inherit from the generic editor and still be able to provide support via the non-generic way. I think that would be non-trivial, but then one "just" has to convince the JDT team to let the Java editor inherit the generic one.
Most "serious" editors (JDT, CDT, JSDT, SSE...) in the Eclipse world do provide some specific extension points to add completion, hover and so on. LSP4E doesn't aim to directly support for each those editors and only allows dependency to Eclipse Platform in order to keep it generic and language-independent. However, ability to use its features in legacy editors is very important. So I suggest you try to create extensions of yours targeting those editors try to re-use the classes provided by LSP4E to enhance those editors. If you have need for package export or even to get some classes turned into APIs, let's use this bug to track your need regarding usage of LSP4E in legacy editors.
Mickael, that is exactly what I had in mind... :-)
New Gerrit change created: https://git.eclipse.org/r/86362
Gerrit change https://git.eclipse.org/r/86362 was merged to [master]. Commit: http://git.eclipse.org/c/lsp4e/lsp4e.git/commit/?id=41fed4d3da515b5825403cc8933ef45bc79d2452
I implemented this as part of the Spring Boot Java language server work that my team is doing at the moment and it is pretty simple and straight forward. You can simply configure a language server via the existing LSP4E extension point for the existing JavaSource content type and implement a JDT IJavaCompletionProposalComputer by calling an LSContentAssistProcessor. That's it. Here is a commit on GitHub that reveals the details: https://github.com/spring-projects/sts4/commit/a5e9f45ea1abd227ef2f969974392bd115063c56 So I think we can close this as "works already"... :-)
(In reply to Martin Lippert from comment #6) > You can simply configure a language server via the existing LSP4E extension > point for the existing JavaSource content type and implement a JDT > IJavaCompletionProposalComputer by calling an LSContentAssistProcessor. > That's it. > > Here is a commit on GitHub that reveals the details: > https://github.com/spring-projects/sts4/commit/ > a5e9f45ea1abd227ef2f969974392bd115063c56 > > So I think we can close this as "works already"... :-) Thanks Martin. It's nice to see that the code binding it to JDT is actually independent from your implementation details and is actually generic of LSP4E. It might be interesting to have LSP4E ship some integrations (as separate bundles) with other projects such as JDT. If you're interested, such contribution would be welcome.
(In reply to Mickael Istria from comment #7) > It might be interesting to have LSP4E ship some integrations (as separate > bundles) with other projects such as JDT. If you're interested, such > contribution would be welcome. I think this would indeed be awesome, and having separate bundles/features that provide integration into various existing editors would be great. I will go ahead and work on some JDT integrations for our spring boot language server and we could indeed try to extract the generic parts out into a contribution for the LSP4E project for sure. So let me go ahead and work on this for a little more (to have more than just a content-assist prototype around) and then consolidate what is there into a contribution for LSP4E.
New Gerrit change created: https://git.eclipse.org/r/160639
I started to contribute the JDT integration for LSP4E that we implemented as part of the Spring Boot Language Server integration for Eclipse. This includes: - integration for content-assist (pretty straight-forward) - integration for hovers: this is a bit more involved, since JDT doesn’t allow multiple hover providers to work for the same piece of code. So we ended up implementing a hover provider that combines the language-server provided hover with the existing Java hover into a combined hover that gets displayed. I added all this to a separate bundle, so that people who would like to use that with their language server can opt-in to use this bundle. The bundle also contains the document setup listener, which automatically starts up language servers that are registered for the Java source content-type whenever a Java editor opens. I have to say that this integration works quite nicely for us for quite a while now, but the integration is also somewhat dangerous, since integrating with JDT can easily damage the user experience in the Java editor if the integration doesn't work well. And hurting the Java editor experience is a pretty dramatic problem when it happens, so I would use this integration with some care. So in order to use this, all you need to do is to implement the language server and register this language server with lsp4e, associate it with the Java source content-type, and you are done. The content-type ID for the Java source content-type is "org.eclipse.jdt.core.javaSource".
Gerrit change https://git.eclipse.org/r/160639 was merged to [master]. Commit: http://git.eclipse.org/c/lsp4e/lsp4e.git/commit/?id=3d0c1258c632ea024873987054e86b0f15e57524
So the above described integration for JDT is in master now. The new bundle that you would need to depend on (in order to use this) is: org.eclipse.lsp4e.jdt
Thanks a lot Martin, that's a great contribution!
