|Re: [ide-dev] News about consuming Language Server in Eclipse IDE|
Cool, we will soon try it out with our Xtext Language Server!We have proposed the lsp4j project (ls-api mentioned above):Any feedback is highly appreciated!Also we are happy to list additional interested parties and would need to find mentors :)Cheers,Sven2016-07-22 13:08 GMT+02:00 Mickael Istria <mistria@xxxxxxxxxx>:_______________________________________________
TL;DR: Come contribute to https://github.com/eclipselabs/eclipse-language-service it's easy, fun and working a little for C# !
As some of you know, at EclipseCon France hackathon, a few contributors started an initiative to consume https://github.com/Microsoft/language-server-protocol designed by VSCode's team to add features to Eclipse IDE. This repository was initiated: https://github.com/eclipselabs/eclipse-language-service .
At the same time, there are ongoing efforts on Platform UI to make it easier to contribute language support to Eclipse IDE, relying on a new generic and extensible (via extensions) code editor which allows to hook various strategies for completion, coloration, hover... https://bugs.eclipse.org/bugs/show_bug.cgi?id=497871
A hackathon on the topic of Language Server took place at VSCode's office a couple of week ago, and I had the opportunity to attend it. Several integration cases were worked on (Java Language Server based on JDT to contribute Java support to VSCode, consumption of Language Server Protocol in Orion, Che and Eclipse IDE). Many interesting step forward were made.Currently, on https://github.com/eclipselabs/eclipse-language-service , there are some extensions to the proposed "Generic Editor" that allow to get completion, error marker and almost Hover from a Language Server. The code is not tied to any new API, so the classes avaiable there can most likely be reused in any case such as in your own editor, or extensions for Java or WTP editors.
I would like to share with you the state of the consumption of Language Service Protocol inside Eclipse IDE.
What's done currently is that the extensions are responsible of starting the right language server (the client currently has to start the server, server are not running daemon one can easily connect to), and then use the https://github.com/TypeFox/ls-api Java client to connect to it via stdin/stdout so far, send requests to language server, get responses, and turn them into the right Eclipse object (IContentAssistProposal, ITextHover...). It's actually not complicated in principle, the code currently isn't very good but it's working and it's easy to improve it, so you're all invited to contribute.
Using it, I could use VSCode's support for CSS and JSon inside Eclipse IDE, but the more interesting example is using https://github.com/OmniSharp/omnisharp-node-client/tree/master/languageserver : once you managed to build it (requires a working dotnet on your machine), then you can use the same code as any other language server to get completion, hover and diagnostics for C# files in Eclipse IDE.
Some of my subjective conclusions:
* Language Server Protocol works pretty well and deliver its promises: factorization, consistency across languages, implement language logic once in a Language Server to have it used trivially by all frontends supporting LSP or committed to support it (VSCode, Che, Orion, Eclipse so far?)
* Once you implement support for LSP in Eclipse, getting all supported languages becomes relatively fast and easy: https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations
* The trend if this get widely adopted is that most dev tools/IDEs will have the same completion, hover... They will manipulate the exact same data so it will drive to more homogeneity and the competition will more happen in the integration choices and how workflows are made accessible to users. For example, in some future where LSP conquered everything, the choice of a dev tools won't happen because one has better completion or other editor features than the others (all will have the same set) but more because one tool better embrace the user workflow, or better guide users in their development. The difference won't be in assisting users to write code, it will be in assisting users in all other development tasks (finding out what to write, feedback loops, debug...)
ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit