[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 16:50:50 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Peter Oliver <p.d.oliver@mavit.org.uk> writes:
> On Fri, 27 Dec 2024, 14:20 Philip Kaludercic, <philipk@posteo.net> wrote:
>
>> Daniel Colascione <dancol@dancol.org> writes:
>>
>> > Why not just vendor all the grammars with the Emacs modes that use them?
>>
>> I am guessing part of the reason is that TS grammars are not fun to
>> build. IIRC they are specified in a Javascript DSL (that used to
>> require node.js but AFAIU works with other implementations as well),
>> that a program written in Rust translates to C code.
>
>
> It's probably worth mentioning that the generated C code is included in the
> Git repositories, these days along with a Makefile. So, if you're only
> building rather than developing the grammars, you can simply run `make &&
> make install` or similar.
Note this isn't practical as the C code is a built time artifact which
is checked into repositories to avoid issues in some of the projects
using the grammars. However that is bad practice for several reasons:
- the grammar is C code yes but it is so big that is effectively a blob.
Doing so duplicates the blob every time it is generated to a degree.
- Since the blob is a build time artifact it is against most
distributions (including GNU I assume) to use these. It is also not
reproducible since it might have been generated by a different
tree-sitter library version, that should not be an issue but still it
isn't right.
- Further it is hard to verify if the blob hasn't been modified after
regenerating.
The practice is temporary and could stop at any point in time. As a
maintainer of some of these grammar packages the checked in grammars
bother me very much.
- Re: Tree-sitter maturity, (continued)
- Re: Tree-sitter maturity, tomas, 2024/12/29
- Re: Tree-sitter maturity, Yuan Fu, 2024/12/29
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/29
- Re: Tree-sitter maturity, Dmitry Gutov, 2024/12/29
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/29
- Re: Tree-sitter maturity, Lynn Winebarger, 2024/12/29
- Re: Tree-sitter maturity, Peter Oliver, 2024/12/28
- Re: Tree-sitter maturity, Philip Kaludercic, 2024/12/28
- Re: Tree-sitter maturity,
Björn Bidar <=
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/27
- Re: Tree-sitter maturity, Daniel Colascione, 2024/12/27
- Re: Tree-sitter maturity, Eli Zaretskii, 2024/12/27
- 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