[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tree-sitter maturity
From: |
Björn Bidar |
Subject: |
Re: Tree-sitter maturity |
Date: |
Sun, 29 Dec 2024 17:05:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Daniel Colascione <dancol@dancol.org> writes:
> On December 27, 2024 9:59:14 AM EST, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Fri, 27 Dec 2024 08:46:06 -0500
>>> From: Daniel Colascione <dancol@dancol.org>
>>> CC: rms@gnu.org, manphiz@gmail.com
>>>
>>> >> 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).
>>> >
>>> >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?
>>> >
>>>
>>> Why not just vendor all the grammars with the Emacs modes that use them?
>>
>>We'd need to ask their developers to agree to this.
>
> Why? They're free software. For copyright assignment? Seems like an exception
> would make sense here.
>
>> Other than that,
>>I don't see how is that different from pointing to a specific version
>>of each grammar: both will be outdated a short time after we point to
>>the version or release Emacs with that version.
>>
>>So why do you think this is better?
>
> Vendoring enables building a full featured Emacs without a network connection
> and guarantees build reproducibility in perpetuity.
Did you think of the long term consequences?
The embedded dependencies would have to be maintained first by Emacs and
later by packagers.
All the infrastructure around syncing of grammars is time spend that
could spend on more long term efforts such as stabilizing the
tree-sitter based modes to not break as easy on grammar changes or to
improve tree-sitter it self.
- Re: Tree-sitter maturity, (continued)
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/27
- Re: Tree-sitter maturity, Stefan Kangas, 2024/12/27
- Re: Tree-sitter maturity, Richard Stallman, 2024/12/28
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/28
- Re: Tree-sitter maturity, tomas, 2024/12/29
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/29
- Re: Tree-sitter maturity, tomas, 2024/12/29
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/29
- Re: Tree-sitter maturity, tomas, 2024/12/29
- Re: Tree-sitter maturity, Björn Bidar, 2024/12/29
- Re: Tree-sitter maturity,
Björn Bidar <=
- 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, 2024/12/27
- 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