emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 20 Dec 2024 11:13:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Yuan Fu <casouri@gmail.com> writes:

>> On Dec 18, 2024, at 5:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> From: Yuan Fu <casouri@gmail.com>
>>> Date: Tue, 17 Dec 2024 14:11:51 -0800
>>> Cc: Peter Oliver <p.d.oliver@mavit.org.uk>,
>>> Stefan Kangas <stefankangas@gmail.com>,
>>> Emacs Devel <emacs-devel@gnu.org>,
>>> Eli Zaretskii <eliz@gnu.org>
>>> 
>>>>> It’s also worth noting that Tree-sitter itself is somewhat
>>>> immature; the developers say that until it reaches version 1.0, we
>>>> should be wary of potentially unannounced incompatible changes
>>>> (although they are trying harder to avoid this, over time).
>>>> 
>>>> 
>>>> [1] https://build.opensuse.org/package/show/editors/tree-sitter
>>> 
>>> I wonder if we can formalize a way for tree-sitter major modes to
>>> state the compatible version of language grammar it uses. Maybe a
>>> package.el cookies, or a variable that set, or even just comments
>>> in the beginning of the file.
>>> 
>>> Many major modes already adds entries to treesit-language-source-alist, 
>>> that could be a good option too.
>>> 
>>> I especially want built-in major modes to give a version, so that
>>> packagers can package Emacs with the right version of tree-sitter
>>> grammar. I know Eli has problems with pinning a grammar version for
>>> builtin modes before, but I wonder what’s he’s stance now?
>> 
>> What's changed?
>
> People are starting to package tree-sitter and tree-sitter
> grammars. If Emacs can be packaged with the right grammars, then
> tree-sitter modes will work out-of-the-box.

Please don't. That would require nodejs to build Emacs bundled with
these grammars. These grammar packages are also not just used with
Emacs.

Grammars are very easy to package once the infrastructure to reuse the
packaging automation in the package manager is there. Don't try to
reinvent that IMHO. If you must generated and build the parser implement
a bindings.gyp parser so you can automate the compilation process
independently of the grammar.

For reference here's my implementation of it in python:
https://build.opensuse.org/projects/editors:tree-sitter/packages/tree-sitter/files/tree-sitter-target.py?expand=1

>> 
>> Many language grammars don't make official releases and thus don't
>> have versions.  Moreover, AFAIK there's no API to determine the
>> version of the grammar library we load.  So how can we manage such
>> version-pinning in a way that (a) is up-to-date, and (b) doesn't
>> preclude people from using a grammar library due to false negatives?
>
> I’m talking about a softer pin. We’re basically providing a “known to
> work” version. This way packagers can package Emacs with a
> known-to-work version of grammar, so the builtin modes work
> out-of-the-box. This doesn’t prevent people from using a newer version
> and sending us a bug report, and we still try our best to make the
> major modes work with the newest grammar.
>
> If the grammar doesn’t have an explicit version, then we can just use a 
> commit hash. I believe all the packaging systems support that?

That doesn't make sense as the versions numbers are arbitrary, e.g. not
always does the version number relate the changes to grammar but also to
the in-tree dependencies in the repository packaging the
language-grammar bindings which have nothing todo with the parser.

What matters much more is the tree-sitter version which is more related
to Emacs itself rather than the particular version of the grammar.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]