elm-language-server-requirements-specification
elm-language-server-requirements-specification copied to clipboard
hakonrossebo
Language Server Protocol
The Language Server Protocol (introduced in this blog post) is used between a tool (the client) and the language server to integrate features used by the client. The protocol is based on JSON-RPC v2.0
Many editors support the Language Server Protocol. This protocol is a set of features/APIs that a language server can expose as part of it's features. An important issue to be resolved here is whether or not ElmLS should implement LSP.
Some IDE authors views on using language server/LSP for Rust here: https://www.reddit.com/r/rust/comments/6fs5q9/language_servers_and_ides/dinhtiz/
TLDR; LSP too limited ? Now of course I suppose our primary target wouldn't be IntelliJ, Eclipse or whatnot but still might give some hints on how modularising the implementation might make it/parts of it more useful.
This is a great find. I assume by modularising, we could still support LSP as one of the interfaces exposed from the language server?
Good to see another language's direct experience with LSP's limitations. I added a comment in the specs doc about a proposal for working outside of the protocol's defined featureset. In short, the elmDocument/{newcommand approach should work for us. In the linked post, the author says that "LSP is inextensible", which is a bit of an exaggeration -- the technology has no specific limitation on what can go through the communication channel. What the author seems to be saying is that extensions are hard to standardize and share between various languages. That's a good point -- but I don't think that means we should ditch the gains we get from adhering to LSP for the parts it does support.
There is already another person who tried to kickstart this: https://github.com/Krzysztof-Cieslak/vscode-elm/issues/137
In my comment here, I already analyzed a bit of the existing tooling. Look at these pointers to see if it would be helpful kicking of things.
@ringods - Thanks for your contributions. I'm the same person starting that issue, working on VSCode-elm and feeling the pain points of re-inventing the wheel to parse some Elm code.
