Eli Zaretskii<eliz@gnu.org> writes:
[...]
> > If they are intersubstitutable, in principle, maybe they ought to have
> > the same user interface so that most users would not notice or care
> > which one is doing the job.
> You are basically asking the same questions I did.
Good that we are following the same line of thinking.
Could you show me the answers you got?
I don't have any answers yet, which is why I posted the questions.
One major difference is that tree sitter does just parsing, and provides
interface to access the returned tree. It works on_one_ file, and does
not care of project semantics, package managers, dependency fetching etc
etc etc. That's LSPs job. Going to references, opening files in
directories outside of the project is also for LSP, thus Eglot.
Returning completions etc etc etc.
Tree-sitter_cannot_ do these things. However, it is fast, which is the
major selling point. That is why you'd want to use that for
indentation, font locking and the simpler things. You can also hack on
tree-sitter. When provided with a proper api it is easy to extend
yourself and add utilities in your own config. Not so much for LSP.
Whatever is to be done must be supported by said server.
They look similar, but in reality they are not. Yes, both can
font-lock, but that's almost where the similarities end.
Because all of the interaction between server and client in lsp is json
there's a huge overhead with parsing and shipping things into the emacs
user interface. So IMO what tree-sitter is good at should be left to
tree-sitter.
(font locking in the server is often just a wrapper of tree-sitter
shipped over json anyways).