bug#26217: bug#2910: 23.0.60; Shell-script coloring bug

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> FWIW, it's not clear at all what such a layer would look like, so we're
>> pretty far from it.  I'd welcome people start thinking about it, maybe
>> by looking at existing alternatives like our own `wisi` (in GNU ELPA),
>> SMIE, maybe LSP (assuming there are servers out there which can provide
>> that kind of functionality), etc...
> I don't know how feasible that would be,

That's the wrong way to look at it.  There is no doubt that it
is feasible.  What is under question is what it would take.

> given that the ts major modes we write have to reference fairly low
> level concerns (such as node names, different across all grammars).

That just means that a given set of highlighting/indentation rules would
not necessarily work with all possible parser-backends.  But maybe we
could bridge the gap by allowing some intermediate layer that could do
things like translate node names (could be useful even within the
tree-sitter context to deal with evolving grammars).

I'm not saying this is the way to go, mind you.  I don't know how it
could/should work.

But I do think we could do worse than start thinking about it, because
tree-sitter is the kind of technology that's on the "treadmill", whereas
Emacs' evolution has a different pace: how well will Emacs-29's TS modes
work with 2028's tree-sitter grammars?

> Maybe porting Lezer (https://lezer.codemirror.net/) could become

Interesting, thanks.

> a replacement in such a scenario, but then we're back to maintaining
> our own grammars again, and with lower performance by an order of
> a magnitude.

We could look into Lezer support just to help us guide the design of an
intermediate layer API.  No need to maintain lots of our own grammars or
take the performance impact :-)


        Stefan