[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tree-sitter maturity
From: |
Eli Zaretskii |
Subject: |
Re: Tree-sitter maturity |
Date: |
Fri, 27 Dec 2024 17:06:10 +0200 |
> 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).
- Re: Tree-sitter maturity, (continued)
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/29
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Message not available
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Message not available
- Message not available
- Re: Tree-sitter maturity, Yuan Fu, 2024/12/29
- Re: Tree-sitter maturity, Philip Kaludercic, 2024/12/27
- Re: Tree-sitter maturity,
Eli Zaretskii <=
- Re: Tree-sitter maturity, Philip Kaludercic, 2024/12/31
- Re: Tree-sitter maturity, Ihor Radchenko, 2024/12/27
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/28
- Re: Tree-sitter maturity, Ihor Radchenko, 2024/12/28
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/28
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Re: Tree-sitter maturity, Richard Stallman, 2024/12/25
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/26
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Message not available
- Re: Tree-sitter maturity, Yuan Fu, 2024/12/23