From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter maturity Date: Sat, 04 Jan 2025 22:12:23 +0200 Message-ID: <86bjwmbaoo.fsf@gnu.org> References: <86ldwdm7xg.fsf@gnu.org> <6765355b.c80a0220.1a6b24.3117SMTPIN_ADDED_BROKEN@mx.google.com> <00554790-CACA-4233-8846-9E091CF1F7AA@gmail.com> <86msgl2red.fsf@gnu.org> <87o710sr7y.fsf@debian-hx90.lan> <8734i9tmze.fsf@posteo.net> <86plldwb7w.fsf@gnu.org> <87ttapryxr.fsf@posteo.net> <0883EB00-3BB2-4BC8-95D1-45F4497C0526@dancol.org> <87msge8bv8.fsf@dancol.org> <6775a459.170a0220.2f3d1e.1897SMTPIN_ADDED_BROKEN@mx.google.com> <87h66emqan.fsf@dancol.org> <86ldvqbe5w.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34830"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, bjorn.bidar@thaodan.de, philipk@posteo.net, emacs-devel@gnu.org, rms@gnu.org, manphiz@gmail.com To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 04 21:13:42 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUAWk-0008xQ-B5 for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jan 2025 21:13:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUAVf-0007IQ-Um; Sat, 04 Jan 2025 15:12:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUAVe-0007IH-D3 for emacs-devel@gnu.org; Sat, 04 Jan 2025 15:12:34 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUAVc-00052N-Ns; Sat, 04 Jan 2025 15:12:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=F+wPO2DLmt+SrT5HyunJIhUyYT27q35x1nt9Uli+79U=; b=Oa0yIcfNhqMu uj6igCWzu6SAM4qI+GefUgKTbtQX6DLV9t4uz4LQDsvfVqNGU+pw7LtAokbU5f7oSvOvTBMWYMCGv Nnysa3Dqvsxm1NhhpOTRCx7HiTyyDKmezoweIxxvYkAC7KtLusWDDIjnvqvKStOm1kawJW6bjNLO8 Nm07090jBchV21b2bWd/CHk9vi9Z3MK015RBSPaV2WdOz+jX5+lwys0IBUElzXvJqq4UFdv1/qvIV nei65Y889is+EZ026K9ygVEbp1TwgbrMbpV/N1K6LiF8zRIwYuegopXOeVZdilC67w1sUfzvKZDZ2 X6bXUmFS8mFHBA/AsmEbZA==; In-Reply-To: (message from Daniel Colascione on Sat, 04 Jan 2025 14:30:30 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327682 Archived-At: > Date: Sat, 04 Jan 2025 14:30:30 -0500 > From: Daniel Colascione > 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.