Comment by z3t4
4 years ago
the language server protocol was a great initiative, it's however very difficult to implement into editors, and the popular language servers, such as the one VScode uses for Python is closed source and only available for VScode...
To be fair, Treesitter is also very hard to use/implement into an editor. It however seem more portable as it can compile to wasm, if you could only figure out how to use it...
I think the problems with Treesitter could be solved with documentation and examples. I don't think the problems with the language server protocol can be fixed as there is too much work to make a full featured language server, so no one will be willing to maintain them.
While the language server turns the editor into a simple io-terminal, Treesitter is like: - here's a tree - you parse it. I would like there to be a middle ground, where you could for example request a list of all variables in scope in the source code on row X. Something ontop of Treesitter, or maybe Treesitter "plugins".
Most language servers are open-source. Microsoft's pylance extension for vscode, is the proprietary version of the open-source pyright server which can be used independently.
A language client is certainly difficult but only has to be created once per editor, and it might be a good thing that the lsp spec is so broad since server authors can implement features at their own pace, while users can have a core subset of features from the start.
I haven't seen any issues with maintenance with any servers I use, though I have seen development on some servers stop when there are better are newer alternatives for a specific language.
You're absolutely right in theory. In practice... well, I've beta-tested two Mac native, non-VSCode editors that have integrated LSP support, and it's become pretty clear that a lot of language servers have only been tested against Visual Studio Code, and sometimes have rather, ah, let's say eccentric interpretations of the spec. (For instance, they may not set mode flags on responses that give guidance to the client; they may ignore initialization flags set by the client telling the server what kind of formats they can handle in responses; they may even crash if the client hasn't implemented a request they expect to be there even if the spec says supporting that is optional.)
I like that LSP has become a multi-editor standard, but I wish language server developers would test their servers against at least a few other editors, or with users of other editors reporting bugs.
What's probably missing is a standard test suite for the protocol... Can't one generate one with model-based testing or another rather automatic mean. Who's the boss of the lsp project? :-)
I'm adding something from my open tabs: https://fitzgeraldnick.com/2020/08/24/writing-a-test-case-ge...
And tsserver doesn't even comply with the LSP spec, which means non-vscode editors need to choice between buggy support for typescript or also implementing a second protocol that is sort of but not quite LSP.
See https://github.com/microsoft/TypeScript/issues/39459
The Theia IDE people have implemented a LSP-wrapper around tsserver [1], which works all right. Of course, the reason that Typescript does not comply to the spec is that it was built before the LSP existed.
[1] https://github.com/theia-ide/typescript-language-server
rust-analyzer [1] goes through the LSP and it's fantastic. It provides an incredibly rich experience nearly on-par with that of TypeScript in VSCode, but for Rust. And it's both third-party and open-source.
[1] https://rust-analyzer.github.io/