| [ide-dev] News about consuming Language Server in Eclipse IDE |
|
Hi all, 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
. 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. 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...) Cheers, |