Re: Tree-sitter maturity

[Eli Zaretskii]

> 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.

> >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.

> > 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).

> > 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.

> >> 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.