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 20:57:15 +0200 Message-ID: <86ldvqbe5w.fsf@gnu.org> References: <67428b3d.c80a0220.2f3036.adbdSMTPIN_ADDED_BROKEN@mx.google.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18998"; 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 19:58:58 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 1tU9MP-0004nk-QY for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jan 2025 19:58:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU9L6-0003SF-5O; Sat, 04 Jan 2025 13:57:36 -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 1tU9L4-0003Rq-8F for emacs-devel@gnu.org; Sat, 04 Jan 2025 13:57: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 1tU9L2-0001PM-7h; Sat, 04 Jan 2025 13:57:32 -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=VFihQSu87phuM0AT6KrSdIenrrFLFVTAVAG5MfuIzV8=; b=HpzROcSKLv08G1vtq2I7 JtOl5R7h8PTGx+wre7RSXBa1JI4KXFEGjBL9WX0QIH9lt+rbFhfVJ9tHbd39DIC8o6dsPU6lAlTmX q6p4btFJpMDimYNAiflzdxMBmMWtB//DWRZC9w/kdr8qBJoBG6Re77DA+wGguMcm31NE5iiqgmFB8 Q1V383WeaoGxssEckWhSTLWW8E/I8DGHsIoOntAfR3ADqV6ZpAhtg7QytucCWy/e0O9dDjg+gPeVx LKF60p7uw5X8A62sYtwgm9cqiWoULfvCkW9aYeAhaGYGO1N+zOoAFsz/InHu+sHWE6RTu7aUSR6Xx nJ7mlwg+y2xnNA==; In-Reply-To: <87h66emqan.fsf@dancol.org> (message from Daniel Colascione on Sat, 04 Jan 2025 12:39:44 -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:327678 Archived-At: > From: Daniel Colascione > Cc: Björn Bidar , Philip > Kaludercic > , emacs-devel , Eli Zaretskii > , Richard Stallman , manphiz@gmail.com > Date: Sat, 04 Jan 2025 12:39:44 -0500 > > The point I keep trying to make is that you can't safely update a > foo-ts-mode tree sitter grammar without updating the corresponding > foo-ts-mode Lisp. They're tightly coupled. They're not separate > programs. Same goes for nvim or whatever using TS grammars. > Even distribution packagers understand the futility of consolidating > dependencies with unstable interfaces. > > When it comes to Emacs, we either 1) treat grammars as part of Emacs and > build them with Emacs, or 2) try to take a runtime dependency on > grammars that can be updated independently of Emacs. > Compatibility considerations mean #2 can't work, so we're left with > doing #1 somehow. This is true in principle, but in practice incompatible changes in grammar libraries are rare. So in practice the same Lisp in foo-ts-mode can endure quite a few changes in the tree-sitter-foo grammar library. > We're not talking about something like libpng, which > could in principle be updated without Emacs having to know about the > update. Libraries like libpng also make incompatible ABI changes from time to time. I agree that they do it less frequently than tree-sitter grammar libraries, but they still do. And yet we don't distribute libpng with Emacs. > The simplest possible way to implement #1 is to just check the grammars > into the Emacs repository and build them with Emacs using the normal > build system. Trying to check in hashes and download the hash-named > grammar versions during the build and *then* build them with Emacs --- > why bother? Because of the hash-locking, a download-at-build-time > scheme doesn't actually add any flexibility relative to just checking in > the code. This eliminates the need to keep the grammar in our repository (or have it sub-moduled), to say nothing of the legal aspects that are better avoided. 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. Other than that, yes, hash-locking is not much more flexible than bundling. I tried to tell that to people who think hash-locking is a solution, but they still insisted. And since they also volunteered to maintain the DB of hashes, I don't see why I should reject that. But I don't think it's a good solution. > 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.