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

[Theodor Thornhill]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> 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.
>
> My comment was more general, as IIUC we are still seeing quite a bit of
> movement even in the low-level fundamentals on that branch, as recently
> as the last week or two.  But if you and others are happy to declare our
> tree-sitter support stable, so much the better.

Only one of the modes is auto-enabled, and that one is because it is
missing support altogether natively in Emacs.  The others are
second-class to their older counterparts, and likely will be for years
to come.  My personal suggestion is to just keep them separate, as
interested parties will find and enable these anyways.  If at some point
tree-sitter is so ubiquitous that it being second class doesn't make
sense anymore we can make it the default.  That's why I don't think we
need to make it experimental: people that will be early adopters will
likely compile emacs from master and get improvements incrementally,
though they should be usable enough for others to use, should a package
manager provide the integration within the stable Emacs 29 package.

I agree with Eli in that providing only the api and "glue-code" would
guarantee that people will just create their own, external variants
that'll be hard to remove should we provide our own down the line.