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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 18 Nov 2022 23:36:30 -0800
> Cc: emacs-devel <emacs-devel@gnu.org>, Theodor Thornhill <theo@thornhill.no>, Eli Zaretskii <eliz@gnu.org>
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
> > The good news is, feature/tree-sitter is merging in a few days! And
> > we’ll make further improvements on the master. So rest assured! :-) I
> > think we can at least get C, Python, Javascript, Typescript, Bash,
> > JONS and CSS to go with the up coming release, largely thanks to
> > Theo’s (and tree-sitter’s) productivity. I personally don’t know
> > enough of C++ and Java to polish them, but they have a good chance
> > too.
> 
> That's very exciting news!  Thanks Yuan, Theodor and all others who
> contributed.
> 
> There seems to be a whole lot of figuring out left to do with both the
> API and how the major modes should be implemented.  Would it make sense
> to ship the `tree-sitter' feature (and related modes) as explicitly
> "experimental", to allow us to make changes in Emacs 30 without overly
> worrying about backwards-compatibility?

The intent is for Emacs 29 to include several modes based on
tree-sitter, and several others to have optional features based on
tree-sitter.  Based on the state of the soon-to-be-merged branch, I
see no reason to declare its support as experimental.

As for backwards-compatibility, you will have to be more specific.
Which features or APIs you see on the branch are in your opinion
likely to change significantly after the release of Emacs 29?  We need
to consider these on a case by case basis.  Personally, I think that
we had this figured out in a way that won't create incompatibilities
and yet allow changes, but maybe I'm missing something.