Re: Tree-sitter maturity

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: rms@gnu.org,  manphiz@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 27 Dec 2024 14:11:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It might take a while for that to happen, which is why I still believe
> >> it would be better if tree-sitter major modes would populate
> >> `treesit-language-source-alist' on their own, and point to the specific
> >> checkouts that the major mode developer tested their implementation
> >> against.
> >
> > We could have done that, but there's no way we could keep the value of
> > treesit-language-source-alist up-to-date, because the grammar
> > libraries put out new versions much more frequently than Emacs
> > releases, especially if you consider libraries that have no official
> > versions at all (in which case we can only point to some revision in
> > their repository).
> 
> Is there a reason we need to keep them *that* up to date?

There is: later versions generally improve on older ones and fix some
bugs.

> What happens when someone is on an older version of Emacs, and with
> Tree Sitter changes in the meantime the current development tip is
> not compatible with the library that Emacs binds against?  It seems
> more reliable to me to pin what commit the grammar was tested
> against, if only as a hint.

It's more reliable, but it could have the effect of keeping people
from upgrading when they can.  What is better?  I don't know.

> > The question that bothers me is how useful is it to have
> > treesit-language-source-alist that is outdated?  What do we expect the
> > users to do with such an outdated value?
> 
> One idea is to first download the pinned version, and if that can't be
> built to download the tip.  We could also prompt the user to check with
> them.

If we do that, it is basically what we have today: the responsibility
for deciding which version to install is on the user.

> If this is a serious issue (which I cannot estimate), we can provide an
> official package similar to the on MELPA with updated references.

Yes, if we have volunteers to keep these up-to-date (which involves
testing the new versions when they come out).