Rabbit hole warning (started by the article linked above):

https://matklad.github.io/2022/04/25/why-lsp.html

https://matklad.github.io/2023/10/12/lsp-could-have-been-bet...

I've implemented a LSP server (for Slint - https://slint.dev) and I agree with this article.

The paradox is that it was meant to avoid to write language support for each editor. Yet, if you want to support vscode you must create a specific extension for it and can't just have a language client.

The article mention the configuration problem, but I'd add the problem that Microsoft refuses to specify a way for the server to tell the client what are the config options so that the client can show some kind UI showing the possible configuration options with a description of what they do. https://github.com/microsoft/language-server-protocol/issues...

RE: "Not a truly open project."

If LSP isn't truly open, then neither are most GNU projects. It was very common for the first 15+ years of GNU's existence for the public development process of a project to be "the single maintainer publishes a release archive whenever they feel like it"

It's a standard freely published and available for all to implement. If that's not "truly open" then we have moved the goalposts way too far.

LSP is pretty ok. Better than the before times I suppose. Although C++ has long had good IDE support so it hasn't affected me too much.

I have a maybe wrong and bad opinion that LSP is actually at the wrong level. Right now every language needs to implement a from scratch implementation of their LSP server. These implementations are HUGE and take YEARS to develop. rust-analyzer is over 365,000 lines of code. And every language has their own massive, independent implementation.

When it comes to debugging all native language support common debug symbol formats. PDB for Windows and DWARF for Nixy things. Any compiled language that uses LLVM gets debug symbols and rich debugging "for free".

I think there should be a common Intellisense Database file format for providing LSP or LSP-like capabilities. Ok sure there will still be per-language work to be done to implement the IDB format. But you'd get like 95% of the implementation for free for any LLVM language. And generating a common IDB format should be a lot simpler than implementing a kajillion LSP protocols.

My dream world has a support file that contains: full debug symbols, full source code, and full intellisense data. It should be trivial to debug old binaries with full debugging, source, and intellisense. This world could exist and is within reach!

> The LSP specification is big. Really big. Last time I checked it had 90 (!) methods and 407 (!!) types. Printing it to a PDF gives you 285 pages (!!!).

Given what it does, that’s pretty dang small. You don’t get all those features across every programming language without some complexity.

Compared to the 3,000+ pages specifications I’ve dealt with, this is easy.

I have a very tiny violin and a cricket to play it for anyone complaining about a few hundred pages. :)

> So I don’t think it’s really a good idea to do a big re-engineering of the protocol just to make it easier for implementers

I'm not so sure. Maybe it's not the case today, but if the protocol eventually becomes so large, so crufty, so under-specified that implementers struggle to provide their implementations, then users suffer.

The article touched on it, but it would be nice if there were a standard way to have extensions for LSP, e.g. a protocol that could be shared by language servers for formal specification languages that need proof obligation support. [0]

[0] http://dx.doi.org/10.4204/EPTCS.338.3

The problem that Microsoft is solving is promotion of VsCode and Visual Studio. Making LSP small and easy to implement would go against that. They want LSP to work well only in their IDEs. Yes, this makes implementing LSP for languages harder, but most of those developers are paid by MS directly or indirectly, in fact making LSP hard also works as a filter against unpaid contributors.

How much easier is it to get the tree-sitter spec implemented for a new language compared to LSP? Are there synergies in getting both to work?

One of my favorite aspects of LSP being 'good enough' is that barebones support is incredibly simple to understand and implement. Old link since it was factored out at some point, but here is the entire LSP implementation for the Micro editor, in ~700 lines of Lua (+ utility functions): https://github.com/AndCake/micro-plugin-lsp/blob/dde90295f09...

Not a LSP developer, but spitballing that perhaps you could address causality by tagging document updates/versions with numbers and messages/replies include the version of the document they correspond to.

[flagged]