Re: Tree-sitter introduction documentation

[Stefan Monnier <monnier@iro.umontreal.ca>]

> My main worry with these changes, along with the popularity of LSP is
> that while they are technological improvements, they all happen at the
> deterioration of Emacs' introspectability, increasing the effort it
> takes for the user to make changes.  IIUC you can't reload a .el file or
> just a singular expression if you want to change how completion via
> Eglot or how imenu works via Tree Sitter.  A simple hack becomes a
> weekend project.  This is not an unconditional good.

Agreed.  Tree-sitter is actually not that bad in this respect: beside
the fact that it requires additional tools to work on the grammar,
"everything else" is under the control of ELisp: Tree-sitter only takes
care of parsing and giving a parse tree without imposing any particular
way to use this information.

So the only thing on which we need to work is making it easier for our
users to hack on the source grammar.  That means helping them fetch that
grammar and helping them figure out which commands to run to generate the
`.c` file from it.  Maybe we could also try and write code that jumps
from a particular position in a buffer to the BNF rule of the
corresponding Tree-sitter node.

LSP is much more problematic because the protocol is structured in a way
that gives a lot of decision making on the server side and the Emacs
side is somewhat limited to supporting or not supporting
a particular feature.  I think this is a large part of the reason why
some languages see a proliferation of different LSP servers: what should
ideally be configured on the editor side is instead "configured" on the
server side by choosing which server you use :-(


        Stefan