Re: Tree-sitter maturity

[Daniel Colascione <dancol@dancol.org>]

On January 4, 2025 3:12:23 PM EST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 04 Jan 2025 14:30:30 -0500
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: owinebar@gmail.com, bjorn.bidar@thaodan.de, philipk@posteo.net,
>>  emacs-devel@gnu.org, rms@gnu.org, manphiz@gmail.com
>> 
>> I think we should vendor even libpng. Down with dynamic linking! Seriousy.
>
>You are asking the Emacs maintenance team to take up a significant
>additional load.  That's impractical.

Tying grammars to the code that uses them is less of a burden than adding hacks upon hacks to try to make Lisp less tightly coupled to grammar changes from the future.

>> >This eliminates the need to keep the grammar in our repository (or
>> >have it sub-moduled)
>> 
>> And it creates the need to do code distribution in a bespoke way. How is that a net win?
>
>It's _our_ win.  The problem is shifted to the distros, where I think
>it belongs.

No, it isn't, because distros *can't* do a good job of this. You have to, for good technical reasons, couple a grammar to a version of Emacs. Besides: plenty of people (I'd guess a majority going by how the industry is set up) were using Emacs outside the context of a distro. If we weren't allergic to telemetry, we'd know.

>> > to say nothing of the legal aspects that are
>> >better avoided.  
>> 
>> Nobody has been able to describe these legal aspects. Grammars are free software. GPL compatible, too.
>> That means we can put them in Emacs. That's what software freedom means.
>
>I did explain that, and don't want to repeat.  You can consider those
>reasons unimportant, but I don't (and cannot, really: I don't call the
>shots in this particular game).

No, you didn't explain. You asserted.

You said that we would need to get written permission from grammar projects to include their code in Emacs. When I asked where this requirement comes from, you said it had always been this way and that RMS might have more information. He appears not to.

That there are legal reasons we can't include third party software in the Emacs repository is superstition. Thousands of other free software projects include third party free code without special permission. At best, the requirement is a hairshirt the project has chosen to wear for no particular reason that that it could choose to remove at any time.

>> > Also don't forget that we have at least two active
>> >branches at any given time, and the number of grammar libraries we are
>> >interested in is more than a handful.  So adding them to our
>> >repository is a significant addition to the maintenance burden.
>> 
>> Vendoring reduces, not increases, the maintenance burden. If you're vendoring or hash locking, when you
>> cut a branch, you cut the grammars at the same time. If you check in the grammars or their hashes, this
>> snapshotting happens automatically. The alternative would be bizarre: we don't try to combine cc-langs.el
>> from master with cc-engine.el from a release branch!
>
>You are missing the point.  My point is that several branches means we
>need to match a different version of the library to each branch

If you check the grammar into the tree, the version in each branch matches that branch automatically. That's what a version control system is. It's the essence of what it does. Same goes for submodules, which are just checked-in pointers.

You do strictly less work to branch when something is just a plain file in that branch than you do when you have some kind of exotic external dependency.

Can you give me a concrete example of how checking in code burdens branch maintenance? Your position isn't making any sense to me in context of how version control systems work.

>> >> It's just a more complicated and error-prone way of doing the
>> >> same thing as checking in the code.  The same goes for other forms of
>> >> downloading dependencies, e.g. via git submodules.
>> >
>> >The difference is that the RI changes.  And that's not something to
>> >ignore, from where I stand.
>> 
>> Huh? In what possible way could a bespoke downloader be a better engineering choice than submodules?
>
>I didn't say anything about engineering, I was talking about the
>responsibility.

Good engineering minimizes the number of moving parts and needless failure points in a system.