Multilspy: Building a common LSP client handtuned for all Language servers | Hacker News Reader

Multilspy: Building a common LSP client handtuned for all Language servers

github.com

It's a bit funny that they use Jedi Language Server for Python as they cannot use Microsoft's own Pylance ("Pylance is licensed for use in Microsoft products and services only, so can only be used on official Microsoft builds of Visual Studio Code and GitHub ...").

They also used Omnisharp Language Server for C# which is deprecated and was replaced with a new extension with custom license terms.

There are no special license terms to using Roslyn Language Server, which is what the base C# extension in VSC uses. It is the debugger which is closed-source, and the custom license terms apply mostly to that debugger and to Dev Kit extension which has a subscription. Both are completely optional and there is also an extension fork which uses NetCoreDbg developed by Samsung and licensed under MIT. It is what people usually use when they debug C# in e.g. Neovim.

Pyright is billed as a "static type checker" but its a full-blown language server (which pylance is built on). I've used both pylance and pyright and frankly I haven't seen any benefit going up to pylance. Pyright is under the MIT license so it can be used for anything: https://github.com/microsoft/pyright/blob/main/LICENSE.txt

I use Pyright as my LSP in Neovim and I’m very pleased with it.

Very cool! I wish this existed a couple years ago. I was hacking with LSP and a Java language server for a code migration prototype, and I could not even get past the initialization stage. The server (must have been the Eclipse one) didn't seem to respond to the initialization params as expected, and I could not find the right documentation or code snippets to figure it out. I eventually implemented the prototype using OpenRewrite. With this, I'm tempted to revive that idea again.

This was precisely the situation I was in! Luckily, the Eclipse JDT.LS contributors are super helpful, and provided me with a lot of their time answering all my questions, which I have now tried to document in as much detail as possible in the Eclipse part of multilspy. My sincere hope is that multilspy can serve as the repository for all other language servers.

I hope you revive "that idea" and I would be glad to help in any way possible w.r.t. multilspy to help you through!

Past discussions on multilspy: https://news.ycombinator.com/item?id=40326391

Great project!

Thank you very much!

I am the author of Monitor-Guided Decoding (https://github.com/microsoft/monitors4codegen), a Language Model Decoding technique that ensures LLM's can generate code while having access to the same kind of feedback that human coders do (like autocompletion, function signature, number of arguments in functions, names of various APIs available across the codebase, etc.). However, building such a technique required a language-agnostic way to interface with various language specific static analyses and indexing features. Language Server Protocol (LSP) is perfect for this!

However, while LSP solves the problem of having a common communication interface to a variety of language-specific servers, the knowledge about each language server's configuration, various options, information on installation/binaries, availability of various LSP features, right way to invoke those is still language specific, and very spread out. As another HN user (antmarti) put it in a previous thread: "As the maintainer of a language server which is primarily used in VSCode, we've relied on community contributions to add support for other editors (NeoVim, Atom, Rider for example). Information about how to do this is spread out, prone to breaking (depending on how well the implementor understood the domain), and also requires the IDE user to follow manual steps in some cases. I don't even know where I would go or who to speak to if (for example) we changed our download URL format, or added new process architectures."

To solve these problems, and while developing Monitor-Guided Decoding, I built multilspy (https://github.com/microsoft/multilspy). It is a framework to build language server clients, which contains hand-tuned configurations (including setup) for how to connect to various language servers (currently supports Java, C#, Python, Javascript and Rust thanks to the amazing open source community contributions). It is still very much the beginning, and a lot of heavily used language servers and features are not supported, but I believe that providing the community with a central repository for different language server configurations will benefit everyone. I would love to receive your feedback, and if you are a language-server implementor, I invite you to kindly add your configuration to multilspy!

Reply on news.ycombinator.com