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:57:48 +0200 Message-ID: <8634hyb8kz.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> <86bjwmbaoo.fsf@gnu.org> <8CE9A18D-79B7-4741-9A7D-6BF90557E456@dancol.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28574"; 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:59:15 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 1tUBEo-0007HM-DV for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jan 2025 21:59:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUBEE-0000GF-Ca; Sat, 04 Jan 2025 15:58:38 -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 1tUBEC-0000Fx-Vp for emacs-devel@gnu.org; Sat, 04 Jan 2025 15:58:37 -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 1tUBEA-0004oN-6O; Sat, 04 Jan 2025 15:58:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:Subject:In-Reply-To:To:From: Date; bh=u2FVjLYRAR31H4Z1CdT+Rj2euMeyiHcDkrB9/h0+n3g=; b=Ix7ImeXCtUoXGtTXMQ5a kPk+1stvOK7rMjtHYyUwyN/iL/C3v6ImfIo+0EIj2/pHQsTSGWYEIGLG0xs96+yj/D9Jxxwylgsmr FMZEgtoQZob5uXyAkvFNmKBoRt2YuoiDUfwOptQqbA2xmNRq2FpAwunY8qMrt7wWvBpfg03Gtc8Rd tn/uRNBbmmRC3ocdoWoN4C713u8XS0C2/oo7UpV5b3LNtop+Z/eVhOCn1s7jVU1PmR2XMI7PKZrJF xE+UamZ9KOMoFM+WUKWcRi+7xfMU8n1sXARmFZc/tW6JrXWQiSCmWHa3fktu6lRmYM1YGqwOmgpZe MdHPWB/0TVCibA==; In-Reply-To: <8CE9A18D-79B7-4741-9A7D-6BF90557E456@dancol.org> (message from Daniel Colascione on Sat, 04 Jan 2025 15:46:49 -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:327685 Archived-At: > Date: Sat, 04 Jan 2025 15:46:49 -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 > > >> 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. Then they need to get their act together and improve. > 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. People who do that (I'm one of them, btw) can build their grammars. I do. > >> 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. RMS explicitly asked me to do that for every package we admit into Emacs. > >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. Again, you are missing the point: we need to find an appropriate version for each branch, and we need to track the versions of the grammar so ass to be able to know, for each of our branches, the compatible version of the grammar. The maintenance burden is multiplied by the branches. > 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. Finding the matching version and testing whether it matches does. > >> >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. Responsibility has nothing to do with engineering or moving parts.