Treesitter knows nothing about your code outside of current file, no? Not to mention all of the project dependencies starting for stdlib.

But a tree sitter mode could parse the related files in the background. That’s exactly what an LSP server does, too.

It's only a parser though, right? So it won't know about derived properties of code like types. I think you still need something like LSP because if the language has type inference, which all modern languages do, you need exactly the same type inference algorithm as the compiler otherwise you'll get incorrect inferences in corner cases.

Most LSP server implementations I've seen are just parsing the source or even stop at just tokenizing it. They don't do anything magical inside the source language (unless a language exposes parsing/compiler internals e.g. like Raku's language server does). So I don't think most LSP servers leverage anything from inside the source language's compiler including performing type inference on your code snippets. Also note: If your code snippet is complete because you are just about typing it, this also cannot work in principle. That's exactly why treesitter was invented: To have a robust static parser able to process incomplete or erroneous code.

> if the language has type inference, which all modern languages do

Well, only if your "modern" language is a statically typed language ... And again: Unless your code is correct and complete, you really can not just run "eval" in your source language and obtain type checking out of the box.

Rust-analyzer provides plenty semantics-level functionality, and it deals with incorrect code gracefully.

I am not a Rust dev. It surely looks great.

However, from what I understand it seems to supply just a parser separate from the Rust compiler (https://github.com/rust-lang/rust-analyzer/tree/master/crate...) trying to keep up with Rust‘s development. So, in principle, it could have been just another treesitter parser plugin, too.

So, again, the LSP framework does not directly provide any magical benefit over a static parsing framework. All the semantic analysis capabilities stem from a good parser.

One benefit is that you don’t have to write a complex tree sitter mode for every editor. You can write an LSP server once and plug it into every editor.

Rust analyzer also provides compilation errors, lints, and code actions. It would be a lot of unnecessary work to implement and maintain these functionalities five times in five different editors.

> Treesitter will make LSP servers obsolete at some point I believe.

that seems extremely unlikely, Treesitter is a vibe-based parser framework for syntax highlighting and indentation of single files, LSP is arbitrary language-specific processes doing full-project parsing and analysis and introspection.

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