Re: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance)

[Eli Zaretskii]

> Date: Fri, 18 Nov 2022 22:54:49 +0100
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> 
> I know this has been said before, by people which by far has been 
> contributing much more than me... But I
> still don't think it's a good idea to replace the implementation in existing 
> major-modes with tree-sitter
> implementations, nor selectively activate tree-sitter in major-modes prone to 
> inhetitence and derivation.
> 
> Me and Theodor faced these same issues with "our" C# and TypeScript 
> major-modes, and the only "clean"
> way we agreed we could make this work was to create wholly new 
> implementations. I can come up with
> many good, objective reasons for this, but I think Theodor has already 
> represented this view fairly well.
> 
> While for the sake of brevity, I'll not diving deeply into this particular 
> thing, I will say this: A new tree-sitter
> based major-mode free of compatibility concerns allowed us to create entirely 
> new major-modes fixing most
> of our existing bugs, faster than we before would be able to fix a single 
> bug. My personal view is that mixing
> existing major-modes with tree-sitter represents absolutely the worst of all 
> worlds. It maintains all existing
> complexities, provides us with very few benefits, and at the same time adds 
> complexities we didn't use to
> have. To me, that's a net negative.
> 
> Somewhat surprising to me, I see this is a somewhat controversial point of 
> view and not as clear cut a
> matter as I would have expected it to be. I realize and respect that final 
> decisions in these matter might take
> some time to mature. Time which given our current approach detracts from the 
> momentum tree-sitter has
> been having.

You are looking at this from the POV of developing these features.
But we have another vantage point to consider: that of our users.
>From their POV, we cannot replace existing modes with completely new
and separate implementations, we must provide a migration path which
will allow users to decide when and whether they want to switch to the
tree-sitter based implementation.  This will also allow us to improve
the tree-sitter support of the modes by collecting user feedback
sooner rather than later.

So we decided to have a hybrid approach: in some modes to provide
separate implementations, and in others to provide optional features
that users can selectively switch on.

> Instead of waiting for "every" major-mode to be re-implemented into a 
> tree-sitter derivative in the
> feature/tree-sitter branch before we merge... How about we just accept the 
> current "core" tree-sitter
> implementation as good enough, and consider merging that to git master as is.

Here you are preaching to the choir, since the decision to merge soon
was already made.  And it cannot be otherwise, since the time of
cutting the emacs-29 release branch is closing up, and we said 2
months ago that we intend to release Emacs 29 with tree-sitter
support.