Hacker News Reader

Comment by ogoffart | Hacker News Reader

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

View on HN

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

> Syntax-coloring and [...] come to mind

Semantic highlighting is part of LSP and supported by all "bigger" LSPs.

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.

I'm not sure if regex engine (or treesitter) + LSP really is faster than just using the LSP, as most of them check the source on typing anyways, so the overhead is sending the tags for the syntax highlighting. And there is no need to send the whole text, the client can send the current edited range only (if the server supports that).

And at least the highlighting would actually be correct (or consistent with the compiler's AST ;).

LSP syntax highlighting supports sending deltas, so it's not true that the whole source gets sent repeatedly.

> Yet, if you want to support vscode you must create a specific extension for it and can't just have a language client.

It’s funny that you generally don’t need to do that for editors like vim or emacs - only need to add a single line in config to specify the command line argument

It honestly depends on how much your LSP server infests the editor. In the language server I wrote there are really 2 cases where we utilize the creation of an editor-specific extension

* dynamic registration of file extensions * display of svg generated by the language server.

We also had to write ad-hoc custom vim-script and would need to do the same for emacs for the first of those, and just dump a URL for vim to punt to a browser for the latter. But it isn't unrealistic to require a custom editor scripts for other editors besides vscode, in the sense that I've done so...

It depends - the client modules for Emacs' `lsp-mode` generally need a fair bit of configuration. Not just how to launch the server, but also often defining a native-compatible way of setting the options. e.g. for Emacs they often get wired up as `defcustom`s.

That's because the LSP makes no assumptions about stuff like (1) what the language server is, (2) how it is launched and managed, (3) how the editor communicates with it, etc. It only defines the format of the communication, nothing else.

In the simplest form the entire language extension in VS Code can be ~15 lines of code that forks the server process and talks with it over stdio. But in complex cases you can:

- Write the entire language server in the extension itself.

- Have your code hosted on a different machine or Docker container.

- Run the editor in a browser and get language support though a service worker or a TCP connection to a remote server.

LSP supports all of this seamlessly because it is agnostic about the transport layer.

Other editors have kind of standardized it to associate a language to a command to run and communicate trough the stdout/stdin. Why do vscode need to be more complicated?

(even this association could be done with a local DB similar to mime types if we wanted to simplify)

I'm pretty torn, on the one hand this tight vscode integration should exist, and is being used to good effect by projects like the lean info-view, which shows the goals of the proof state. And my own project which e.g. generates railroad diagrams and displays them in the editor.

On the other hand, it is kind of unfortunate that this sort of tight integration with language server and editor is happening in the editor which drives/governs the specification itself. I think it would be much more tolerable in regards to the future of the specification if these sorts of "above and beyond" integrations were all happening in any other editor.

The approach that you mention has its limitations, and what many (most?) editors do is quite a bit more complex than that.

For example, I don't want a new LSP instance for each file, I want to re-use the same LSP instance if files belong to the same project. For this, my editor needs to understand which directory is the root of the project, and this varies per-language.

In case of neovim, there's a nvim-lspconfig plugin that ships all this configuration and lots of other little nuances. I guess the folks from VSCode preferred lots of little plugins instead of a single big one.

Reply on news.ycombinator.com