> LSP is arbitrary language-specific processes doing full-project parsing and analysis and introspection No. LSP is a way of separating the job of parsing and

> LSP is arbitrary language-specific processes doing full-project parsing and analysis and introspection No. LSP is a way of separating the job of parsing and static analysis of a source file from the editor and doing it out of process. It's a neat concept for sure moving the burden of implementation from the editor's maintainers over to the language project. But all language servers really do is performing static parsing and analysis. Some language servers even skip full parsing and just use the plain tokens from the input file (which still works okay for many languages). I suggest people actually take a look into the implementations of various language servers. It is quite disillusioning. When I first heard about LSP I was under the impression it was hooking into the actual language's implementation. But this is really not the case. For example, the deno-based JavaScript language server does not even leverage V8's javascript interpreter but comes with a full re-implementation of a static JavaScript parser written in Rust. My argument is: You could all have that also using just the treesitter framework because the editor only needs to load the grammar for any language from an external plugin and provide a generic querying API (the treesitter even comes with that and e.g. Emacs just provides Elisp bindings for that AFAIU). The language modes could then leverage the parser to do all the hefty work that currently language servers do but inside the editor's process and, hence, without the overhead of IPC. There is also no single-file limitation. Nothing stops a language mode from parsing include statements and open the corresponding files.