Langserver.org – A community-driven source for Language Server implementations

I have to say that list has gotten waaay longer since last time I saw it. LSP really has been a massive success, and despite being made by MS, has been one of the main reasons I’ve been able to keep using Emacs and not migrated to other more IDE-like editors. MS deserves som serious credit here for being one of the few players willing to think in protocols these days. Protocols vs products makes a big difference.

I still don't get it. We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of language servers but would also allow more use-cases in the future (e.g. IntelliJ-style inspections or language-aware diffs). Instead, the standard requires running half a dozen processes with an API that doesn't provide anything except the exact data required for a number of handpicked use-cases. Considering that even…

Context: the "Language Server Protocol" is what Visual Studio Code uses to provide language features (auto completion, error checking, navigation, etc) via a separate process. More than tying it to VSC, though, Microsoft decided to make it a separate standard that can be implemented by other editors and IDEs. This website lists popular LSP implementations and clients (editors) who support it.

>"Why LSP? LSP creates the opportunity to reduce the m-times-n complexity problem of providing a high level of support for any programming language in any editor, IDE, or client endpoint to a simpler m-plus-n problem. For example, instead of the traditional practice of building a Python plugin for VSCode, a Python plugin for Sublime Text, a Python plugin for Vim, a Python plugin for Sourcegraph, and so on, for every language, LSP allows language communities to concentrate their efforts on…