19 ms·

LSP: The good, the bad, and the ugly

280 points by bryjnar 2y ago

yurbikey3 2y ago
[flagged]
oblio 2y ago
Rabbit hole warning (started by the article linked above): https://matklad.github.io/2022/04/25/why-lsp.html https://matklad.github.io/2022/04/25/why-lsp.html https://matklad.github.io/2023/10/12/lsp-could-have-been-better.html https://matklad.github.io/2023/10/12/lsp-could-have-been-bet...
- sestep 2y ago
  That 2022 post is amazing, thanks for the link!
- matklad 2y ago
  And https://rust-analyzer.github.io/blog/2020/07/20/three-architectures-for-responsive-ide.html https://rust-analyzer.github.io/blog/2020/07/20/three-archit... Is a must-read if you are to build your own LSP server!
aidenn0 2y ago
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.
- aithrowaway1987 2y ago
  But that is not the standard for current GNU projects in large part because of all the easily avoidable friction. "If it was good enough for Richard Stallman in 1987, it's good enough for Microsoft in 2024" is just a dumb argument. Not to mention you're conflating apples with oranges, since a software standard is very different from an application. POSIX wasn't just one Bell Labs employee working by himself. From the article: > The LSP should be an open standard, like HTTP, with an open committee that represents the large community which is invested in LSP, and can offer their insight in how to evolve it. There is no goalpost moving here.
  - deleted 2y ago
    [deleted]
  - cryptonector 2y ago
    Building and maintaining a community is hard work. Even just talking to all comers is hard work. You need a team for that, but if you're a team of one then the community is likely going to suffer. You could find external contributors to promote to committers, but that's work too, and maybe LSP's maintainer doesn't want that (or maybe LSP's maintainer's employer (MSFT) doesn't want that). Apart from what MSFT wants, the rest is just as likely to happen for small enough projects whether they be GNU projects or not.
- deleted 2y ago
  [deleted]
- leni536 2y ago
  Most GNU projects are typically not standards/specifications but programs and libraries. That's a significant difference IMO.
- kayodelycaon 2y ago
  Yeah… this is can be confusing. “Open source”, “open standard”, and “open project” are different concepts. The first two are well-defined and LSP meets the criteria for both. “Open project” doesn’t have a definition or criteria. In this case, it probably means the community using a standard, controls the standard. The http protocol is an example of this. Ultimately, they think the people in charge of the project are not listening to the people using it. This is a serious concern. However, making a project “open” does not fix this problem. See systemd. I hate dropping Wikipedia links but here is open standard: https://en.m.wikipedia.org/wiki/Open_standard https://en.m.wikipedia.org/wiki/Open_standard
  - deleted 2y ago
    [deleted]
- kelnos 2y ago
  Two things: 1. (As another commenter mentioned) Most GNU projects are not standards that are expected to be adopted by a significant number of implementers, and used by a huge number of users. Most GNU projects are totally fine having a few maintainers. 2. I am a lot more comfortable with a GNU project being run by a single maintainer than a public specification being owned by a corporation, where changes to that specification are largely driven by that company's product choices and profit motive. And regardless, it seems a little weird to compare the GNU of the 80s and 90s to any public project today. In GNU's first 15 years the internet was nascent (at best!), and the number of people who implemented, used, and cared about these sorts of things were orders of magnitude smaller than they are today. Needs have changed.
- jchw 2y ago
  I think "truly open" is not specific enough. Not being developed "in the open" is one thing, not having "open governance" is another thing. That said, I guess the problem here is that for standards it helps if well, you collaborate with the people for which the standard is meant to be used by, which is presumably a little hard if there's a huge asymmetric relationship when it comes to Microsoft's concerns vs the rest of the world's concerns. This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable. If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? LSP is really just the beginning, since there are plenty of things that editors would probably like to integrate deeper with, such as build systems.
  - aidenn0 2y ago
    > This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable. I think a committee is a reasonable backup plan, and can even be done without Dirk's approval (see e.g. WHATWG done without the W3C's approval). If the LSP continues to be "good enough" then it seems unlikely. > If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
    - jchw 2y ago
      Yes I certainly agree, there is not really much of an impetus for this to happen right away or anything. In the long term, though, I do suspect it is inevitable. > Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience. I have some thoughts: - I think there will be more. At the very least, I suspect there is a reasonable chance Apple/XCode would eventually adopt LSP. - Realistically, there aren't that many browser engines either. There's really just two truly distinct browser engines, and really only one of them is the main product of the company that produces it. Arguably there are already more distinct text editor engines that have LSP clients built-in today: Neovim, VSCode/Monaco, Visual Studio, IntelliJ IDEA, Eclipse, Zed, and probably more I'm not thinking of. - I think that it is likely LSP clients will continue to appear in more places. In "cloud compute" UIs for things like serverless functions, inside of code forge's built-in editors, and so forth. It's not that it's necessarily that it's so easy to do it well, it's more that the value:effort ratio of doing it is pretty great, and every time someone develops a new high-quality LSP, it gets even better.
pama 2y ago
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?
- kriiuuu 2y ago
  Significantly easier because there is just a lot less surface area.
- IshKebab 2y ago
  Tree Sitter doesn't do a tenth of what most LSP servers do, so it's much easier. But they aren't really related. Tree Sitter is a parser that you might use in an LSP server (I have done; worked decently).
- ramon156 2y ago
  Apples to Oranges
- ReleaseCandidat 2y ago
  Treesitter is the wrong solution anyway. The biggest advantage of LSP is that the parser, type checker,... used by the LSP is (well, can and should be) the same as the one used in the compiler (or at least another _complete_ implementation of the language, like clang for gcc/g++).
  - rkangel 2y ago
    Worth noting that major languages seem to be moving away from this model. Rust and C# both concluded that the needs of your actual compiler are very different than the needs of an incremental tool that can run on partially written code.
kayodelycaon 2y ago
> 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. :)
- saghm 2y ago
  What sticks out to me is that there's less than one method per every four types. Given that, I assume that most of these types are just plain structs or type aliases; in other words, just names for things. I'm not sure what the author is trying to convey with that; would it be better if there were half as many types but they all had twice as many fields and methods and had to get used for multiple purposes? If the scope of the project is too large, that's certainly a valid complaint, but independent of somehow measuring the expected "size" of an API to cover a given scope, I don't really see how these raw numbers are particularly concerning. I'd be more concerned if the ratio of methods to types were reversed, but still a bit skeptical of any significance without more context.
  - kayodelycaon 2y ago
    For comparison, YAML is 77 pages.
    - saghm 2y ago
      YAML is a data serialization language that doesn't have any concept of "execution"; LSP needs to encode not just one full programming language semantics, but _arbitrary_ programming language semantics. YAML's spec being over 3/4 the size of LSP is a lot more damning to YAML to me.
      - kayodelycaon 2y ago
        YAML is known to be incredibly complex and nuanced, which is why I choose it as a comparison. Also, 77 is 37% of 285.
forrestthewoods 2y ago
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!
- PoignardAzur 2y ago
  > rust-analyzer is over 365,000 lines of code. That has nothing to do with LSP. Rust Analyzer is similar in scope to a second implementation of the Rust compiler.
  - forrestthewoods 2y ago
    > similar in scope to a second implementation of the Rust compiler. I know. That’s really bad!
    - nobodywasishere 2y ago
      I disagree. A compiler for batch building programs and a compiler for providing as much semantic information about incomplete/incorrect/constantly changing programs are completely different tasks that require completely different architectures and design considerations.
csb6 2y ago
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 http://dx.doi.org/10.4204/EPTCS.338.3
kelnos 2y ago
> 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.
ogoffart 2y ago
I've implemented a LSP server (for Slint - https://slint.dev 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/1640 https://github.com/microsoft/language-server-protocol/issues...
- dualogy 2y ago
  > 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. On the one hand, this has always bugged me slightly. But on the other hand, every time when it came down to it in practice, I realized two things: first, a VSC extension that does nothing but wire up the LSP language clienting library is a tiny project with no major maintenance burden; and secondly, more importantly you usually want additional language-extension client-side features that are editor-specific by nature and either couldn't or shouldn't be abstracted-inside / covered-by the language-server / lang intel / IntelliSense realm. Syntax-coloring and other grammar-describing meta-data come to mind, or custom Notebook, or rich & productive build or debug or pkg-mgmt etc. helpers & tooling UX, etc. Stuff that arguably belongs in one's "language extension" but is mostly editor-specific and thus at the same time doesn't truly belong in one's "language intelligence serving".
  - ReleaseCandidat 2y ago
    > Syntax-coloring and [...] come to mind Semantic highlighting is part of LSP and supported by all "bigger" LSPs.
    - legrangramgroum 2y ago
      LSP syntax highlighting can be heavy weight the whole source is sent every few keystroke, and if many tokens get an annotation. It is common to use fast and simple JS frontend highlighting for simple things like literals, keyword and comments. For example, with Textmate via a VSCode extension. LSP is left to deal with the identifiers where a name resolver or a type system is needed.
nyanpasu64 2y ago
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.
- bryjnar 2y ago
  LSP does do this, but inconsistently. Document versions aren't always sent (e.g. nothing relating to diagnostics uses them). It's also not enough to send the versions: you need to actually say what to do with them!
sesm 2y ago
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.
- eropple 2y ago
  Having read the LSP specification, and when I take into account just how many things LSP does, I think a 285-page spec is really tiny. I have specs on my work computer with TMF and CAMARA specs that are nearly 100 pages just to talk about the operation of a half-dozen methods--and there's still ambiguity in them at times. Coupling that genuine brevity with the ability to avoid serious backwards-compatibility problems makes this charge feel pretty outlandish, TBH.
- zarzavat 2y ago
  When it comes to IDEs, small and easy = uncompetitive. Most users want to use the IDE that saves them the most time and has the features they want, they are not concerned with implementation complexity because that’s someone else’s job. If you reduce all the complexity of a competitive IDE to a protocol then you get something as complicated as LSP. That’s just how it is.
pie_flavor 2y ago
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/dde90295f09b48094ee262ec00cd8731604a6dd8/main.lua https://github.com/AndCake/micro-plugin-lsp/blob/dde90295f09...
- bryjnar 2y ago
  Admittedly my proposal to build everything off more powerful state synchronization primitives does raise the bar for getting _something_ working. Ideally you make it so you can progressively support more features, still. But sometimes you do have to choose between "easy at first, then gets progressively harder" vs "hard at first, then stays manageable".

280 points by bryjnar 2y ago

[flagged]

Rabbit hole warning (started by the article linked above): https://matklad.github.io/2022/04/25/why-lsp.html https://matklad.github.io/2022/04/25/why-lsp.html https://matklad.github.io/2023/10/12/lsp-could-have-been-better.html https://matklad.github.io/2023/10/12/lsp-could-have-been-bet...

sestep 2y ago
That 2022 post is amazing, thanks for the link!
matklad 2y ago
And https://rust-analyzer.github.io/blog/2020/07/20/three-architectures-for-responsive-ide.html https://rust-analyzer.github.io/blog/2020/07/20/three-archit... Is a must-read if you are to build your own LSP server!

aidenn0 2y ago

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.

aithrowaway1987 2y ago
But that is not the standard for current GNU projects in large part because of all the easily avoidable friction. "If it was good enough for Richard Stallman in 1987, it's good enough for Microsoft in 2024" is just a dumb argument. Not to mention you're conflating apples with oranges, since a software standard is very different from an application. POSIX wasn't just one Bell Labs employee working by himself. From the article: > The LSP should be an open standard, like HTTP, with an open committee that represents the large community which is invested in LSP, and can offer their insight in how to evolve it. There is no goalpost moving here.
- deleted 2y ago
  [deleted]
- cryptonector 2y ago
  Building and maintaining a community is hard work. Even just talking to all comers is hard work. You need a team for that, but if you're a team of one then the community is likely going to suffer. You could find external contributors to promote to committers, but that's work too, and maybe LSP's maintainer doesn't want that (or maybe LSP's maintainer's employer (MSFT) doesn't want that). Apart from what MSFT wants, the rest is just as likely to happen for small enough projects whether they be GNU projects or not.
deleted 2y ago
[deleted]
leni536 2y ago
Most GNU projects are typically not standards/specifications but programs and libraries. That's a significant difference IMO.
kayodelycaon 2y ago
Yeah… this is can be confusing. “Open source”, “open standard”, and “open project” are different concepts. The first two are well-defined and LSP meets the criteria for both. “Open project” doesn’t have a definition or criteria. In this case, it probably means the community using a standard, controls the standard. The http protocol is an example of this. Ultimately, they think the people in charge of the project are not listening to the people using it. This is a serious concern. However, making a project “open” does not fix this problem. See systemd. I hate dropping Wikipedia links but here is open standard: https://en.m.wikipedia.org/wiki/Open_standard https://en.m.wikipedia.org/wiki/Open_standard
- deleted 2y ago
  [deleted]
kelnos 2y ago
Two things: 1. (As another commenter mentioned) Most GNU projects are not standards that are expected to be adopted by a significant number of implementers, and used by a huge number of users. Most GNU projects are totally fine having a few maintainers. 2. I am a lot more comfortable with a GNU project being run by a single maintainer than a public specification being owned by a corporation, where changes to that specification are largely driven by that company's product choices and profit motive. And regardless, it seems a little weird to compare the GNU of the 80s and 90s to any public project today. In GNU's first 15 years the internet was nascent (at best!), and the number of people who implemented, used, and cared about these sorts of things were orders of magnitude smaller than they are today. Needs have changed.
jchw 2y ago
I think "truly open" is not specific enough. Not being developed "in the open" is one thing, not having "open governance" is another thing. That said, I guess the problem here is that for standards it helps if well, you collaborate with the people for which the standard is meant to be used by, which is presumably a little hard if there's a huge asymmetric relationship when it comes to Microsoft's concerns vs the rest of the world's concerns. This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable. If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? LSP is really just the beginning, since there are plenty of things that editors would probably like to integrate deeper with, such as build systems.
- aidenn0 2y ago
  > This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable. I think a committee is a reasonable backup plan, and can even be done without Dirk's approval (see e.g. WHATWG done without the W3C's approval). If the LSP continues to be "good enough" then it seems unlikely. > If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
  - jchw 2y ago
    Yes I certainly agree, there is not really much of an impetus for this to happen right away or anything. In the long term, though, I do suspect it is inevitable. > Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience. I have some thoughts: - I think there will be more. At the very least, I suspect there is a reasonable chance Apple/XCode would eventually adopt LSP. - Realistically, there aren't that many browser engines either. There's really just two truly distinct browser engines, and really only one of them is the main product of the company that produces it. Arguably there are already more distinct text editor engines that have LSP clients built-in today: Neovim, VSCode/Monaco, Visual Studio, IntelliJ IDEA, Eclipse, Zed, and probably more I'm not thinking of. - I think that it is likely LSP clients will continue to appear in more places. In "cloud compute" UIs for things like serverless functions, inside of code forge's built-in editors, and so forth. It's not that it's necessarily that it's so easy to do it well, it's more that the value:effort ratio of doing it is pretty great, and every time someone develops a new high-quality LSP, it gets even better.

pama 2y ago

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?

kriiuuu 2y ago
Significantly easier because there is just a lot less surface area.
IshKebab 2y ago
Tree Sitter doesn't do a tenth of what most LSP servers do, so it's much easier. But they aren't really related. Tree Sitter is a parser that you might use in an LSP server (I have done; worked decently).
ramon156 2y ago
Apples to Oranges
ReleaseCandidat 2y ago
Treesitter is the wrong solution anyway. The biggest advantage of LSP is that the parser, type checker,... used by the LSP is (well, can and should be) the same as the one used in the compiler (or at least another _complete_ implementation of the language, like clang for gcc/g++).
- rkangel 2y ago
  Worth noting that major languages seem to be moving away from this model. Rust and C# both concluded that the needs of your actual compiler are very different than the needs of an incremental tool that can run on partially written code.

kayodelycaon 2y ago

> 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. :)

saghm 2y ago
What sticks out to me is that there's less than one method per every four types. Given that, I assume that most of these types are just plain structs or type aliases; in other words, just names for things. I'm not sure what the author is trying to convey with that; would it be better if there were half as many types but they all had twice as many fields and methods and had to get used for multiple purposes? If the scope of the project is too large, that's certainly a valid complaint, but independent of somehow measuring the expected "size" of an API to cover a given scope, I don't really see how these raw numbers are particularly concerning. I'd be more concerned if the ratio of methods to types were reversed, but still a bit skeptical of any significance without more context.
- kayodelycaon 2y ago
  For comparison, YAML is 77 pages.
  - saghm 2y ago
    YAML is a data serialization language that doesn't have any concept of "execution"; LSP needs to encode not just one full programming language semantics, but _arbitrary_ programming language semantics. YAML's spec being over 3/4 the size of LSP is a lot more damning to YAML to me.
    - kayodelycaon 2y ago
      YAML is known to be incredibly complex and nuanced, which is why I choose it as a comparison. Also, 77 is 37% of 285.

forrestthewoods 2y ago

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!

PoignardAzur 2y ago
> rust-analyzer is over 365,000 lines of code. That has nothing to do with LSP. Rust Analyzer is similar in scope to a second implementation of the Rust compiler.
- forrestthewoods 2y ago
  > similar in scope to a second implementation of the Rust compiler. I know. That’s really bad!
  - nobodywasishere 2y ago
    I disagree. A compiler for batch building programs and a compiler for providing as much semantic information about incomplete/incorrect/constantly changing programs are completely different tasks that require completely different architectures and design considerations.

csb6 2y ago

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 http://dx.doi.org/10.4204/EPTCS.338.3

kelnos 2y ago

> 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.

ogoffart 2y ago

I've implemented a LSP server (for Slint - https://slint.dev 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/1640 https://github.com/microsoft/language-server-protocol/issues...

dualogy 2y ago
> 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. On the one hand, this has always bugged me slightly. But on the other hand, every time when it came down to it in practice, I realized two things: first, a VSC extension that does nothing but wire up the LSP language clienting library is a tiny project with no major maintenance burden; and secondly, more importantly you usually want additional language-extension client-side features that are editor-specific by nature and either couldn't or shouldn't be abstracted-inside / covered-by the language-server / lang intel / IntelliSense realm. Syntax-coloring and other grammar-describing meta-data come to mind, or custom Notebook, or rich & productive build or debug or pkg-mgmt etc. helpers & tooling UX, etc. Stuff that arguably belongs in one's "language extension" but is mostly editor-specific and thus at the same time doesn't truly belong in one's "language intelligence serving".
- ReleaseCandidat 2y ago
  > Syntax-coloring and [...] come to mind Semantic highlighting is part of LSP and supported by all "bigger" LSPs.
  - legrangramgroum 2y ago
    LSP syntax highlighting can be heavy weight the whole source is sent every few keystroke, and if many tokens get an annotation. It is common to use fast and simple JS frontend highlighting for simple things like literals, keyword and comments. For example, with Textmate via a VSCode extension. LSP is left to deal with the identifiers where a name resolver or a type system is needed.

nyanpasu64 2y ago

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.

bryjnar 2y ago
LSP does do this, but inconsistently. Document versions aren't always sent (e.g. nothing relating to diagnostics uses them). It's also not enough to send the versions: you need to actually say what to do with them!

sesm 2y ago

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.

eropple 2y ago
Having read the LSP specification, and when I take into account just how many things LSP does, I think a 285-page spec is really tiny. I have specs on my work computer with TMF and CAMARA specs that are nearly 100 pages just to talk about the operation of a half-dozen methods--and there's still ambiguity in them at times. Coupling that genuine brevity with the ability to avoid serious backwards-compatibility problems makes this charge feel pretty outlandish, TBH.
zarzavat 2y ago
When it comes to IDEs, small and easy = uncompetitive. Most users want to use the IDE that saves them the most time and has the features they want, they are not concerned with implementation complexity because that’s someone else’s job. If you reduce all the complexity of a competitive IDE to a protocol then you get something as complicated as LSP. That’s just how it is.

pie_flavor 2y ago

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/dde90295f09b48094ee262ec00cd8731604a6dd8/main.lua https://github.com/AndCake/micro-plugin-lsp/blob/dde90295f09...

bryjnar 2y ago
Admittedly my proposal to build everything off more powerful state synchronization primitives does raise the bar for getting _something_ working. Ideally you make it so you can progressively support more features, still. But sometimes you do have to choose between "easy at first, then gets progressively harder" vs "hard at first, then stays manageable".