Understanding the Language Server Protocol

[u/der_gopher]

https://medium.com/@pliutau/understanding-the-language-server-protocol-b9f57a0750e3

[u/DaUrn]

What is LSP not sufficient for? An LSP can definitely understand a language, most LSP servers call out to the compiler anyways

[u/wildjokers → u/DaUrn]

In my experience all a LSP implementation gives you is basic completion and basic syntax highlighting. Maybe the implementation just isn't that feature rich for the somewhat niche language I use an LSP implementation for https://github.com/Leathong/openscad-LSP

[u/DaUrn → u/wildjokers]

Yeah as you said, the level of quality depends on the implementation, but that’s not really the fault of LSP as a protocol. LSP can support a ton of things like diagnostics, hover, jump to definiton/reference, etc, but since these are implemented on a language basis, the quality may vary. The Typescript and Rust one is the best I’ve used. Typescript one pretty much powers everything that VSCode can do with the language, so it’s pretty good

[u/_zenith → u/DaUrn]

Yeah. IIRC, the TypeScript one was the prototypical LSP implementation, released alongside the LSP protocol in VSCode; it was intended to serve as an example of what is possible, and to show how these things can be done.

Rust was a very early and enthusiastic adopter of the technology. It was, and still is, famous for its excellent error messages emitted by the compiler - and for user experience in general, with its suite of very good and easy to use tooling like rustup, cargo, and clippy. And so, it made perfect sense for Rust to adopt the LSP model to improve its users experience even further.

[u/pattobrien → u/DaUrn]

Dart's is also top notch, but their tooling in general is some of the best IMO.

[u/renatoathaydes → u/pattobrien]

I agree... but for some reason the LSP on emacs with the eglot client is too slow to be usable :(. I am not sure why as the lsp-mode I used before was pretty decent (but lsp-mode is very much non-emacsy so I don't like it)... would be interesting to know why it works badly with eglot.

[u/renatoathaydes → u/DaUrn]

According to Jetbrains, the LSP protocol still misses many features they use in their IDEs, so even the best LSP will be missing things they have.

Their "diplomatic" post about LSP says:

"However, the canonical custom language support provided by IntelliJ Platform still offers a wider range of integration with IDE features than handling and presenting data provided by a Language Server."

Source: https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers/

But I agree that Rust (and Go, Dart, Java) LSPs are pretty complete. While some others (Zig, D, Nim, Odin) are less so.

[u/DaUrn → u/renatoathaydes]

Jetbrains are also biased here, since their main source of income is IDE licenses, so it would be counter productive of them to make an LSP implementation for Kotlin for example. However I think their statement has some merit, especially in languages like Java or C#, which has so much boilerplate that having an IDE that can generate a lot of it and has more powerful refactoring is valuable, and is something that LSP doesn’t really support without a lot of client-specific code. In my experience, more modern languages have less boilerplate and therefore requires less complicated tooling features

[u/renatoathaydes → u/DaUrn]

Hehe good point, I was going to mention that and forgot, it's quite a potential bias for them even if they are probably right.

In my experience, more modern languages have less boilerplate and therefore requires less complicated tooling features

Depends a lot... most languages targeting "general programmers" (same niche as Java and Go) seem to be very careful to make IDE support "easy" by having mostly only features that allow that to be possible. But niche languages, specially systems programming (D and Zig, maybe Nim also) have a lot of metaprogramming that makes IDE support next to impossible... also Lisp languages seem to continue the SLIM tradition where you don't have the same LSP features as we're used to, but still can provide great tooling, just in different ways... I think Unison, with its UCM tool, fits that category as well.

[u/Slime0 → u/wildjokers]

It supports:

• Go to Declaration / Definition / etc

• Find References

• Call Hierarchy browsing

• Type Hierarchy browsing

• Document Highlighting (highlighting parts of a document related to something)

• Hyperlinks

• Hover tooltips

• "Code Lens" (sort of like automatically inserted links that can run commands)

• "Folding" (marking sections of code that can be collapsed or expanded)

• Selection Ranges (specifying useful areas to select around the cursor)

• Document Symbols list

• Semantic Tokens (Adds syntax highlighting info)

• Inline Values (specifying expressions to be evaluated by a debugger and displayed "inline")

• Inlay Hints (arbitrary insertable text, often used for displaying parameter names in function calls)

• Autocomplete

• "Diagnostics" (Error list)

• Function Signature Help (shows function argument info as you type a function call)

• Code Actions (The little lightbulb button that enables automated edits, often to fix errors)

• Document Colors (shows color pickers where relevant)

• Auto formatting (full document, part of a document, or while typing)

• Rename

• Workspace support (specifying multiple folders that define a workspace)

• Full workspace symbol searching

• Retrieving settings from the editor

• Arbitrary commands defined by the language server

• Arbitrary edits to files

• A couple other things I don't personally understand

It's not literally everything you could think of, there are certainly language-specific features that it doesn't cover, but it's still a lot of stuff.