From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter maturity Date: Tue, 31 Dec 2024 13:47:19 +0000 Message-ID: <87msgc2cd4.fsf@posteo.net> References: <1ed88fca-788a-fe9f-b6c8-edb2f49751c9@mavit.org.uk> <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> <87y101rzbe.fsf@posteo.net> <86frm9w4gt.fsf@gnu.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="1428"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, manphiz@gmail.com, emacs-devel@gnu.org, Yuan Fu To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 14:48:30 2024 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 1tScbk-0000Ah-UI for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 14:48:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tScb0-0001BC-7P; Tue, 31 Dec 2024 08:47:42 -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 1tScav-0001AV-Kw for emacs-devel@gnu.org; Tue, 31 Dec 2024 08:47:37 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tScat-0004b5-Gr for emacs-devel@gnu.org; Tue, 31 Dec 2024 08:47:37 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 20646240027 for ; Tue, 31 Dec 2024 14:47:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735652841; bh=kfsnUQ1eq/G9iPYwftaEmoa7+joJpgME+buwKIkj4BA=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=F8mziXeEukdDCp+KoZY9azIAxUlMgknTeZK99b2SSRqrklfneOePsnxlEea94knYX Azlh/wPGjbCepmrw1lvtPs15dgyG5dBqXUZKVU0pQtKS0m05RDId5BwCbeHb3Jnm6S x8Do5FHI5deRarb0Bu1U0rdbnuJ9pO2YJjr/YQobQj0Awlb/7S/DBDj2QHcXdzh5Tx 6GsL6k82moOnpGydhLwlNdFZI5+rk0zB/SAgaSvcYvbbGHI/EZF7EVEZZYYTRqzQoq K140xT95NZX+SopBOVlkY5Tq6bVGW5Ehl2PtfSD4/mA8H2YSUwRQb9rNwnidhc14A3 mN86sDNtgXZwQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YMvRD2RNBz6tvl; Tue, 31 Dec 2024 14:47:20 +0100 (CET) In-Reply-To: <86frm9w4gt.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Dec 2024 17:06:10 +0200") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:327502 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: rms@gnu.org, manphiz@gmail.com, emacs-devel@gnu.org >> Date: Fri, 27 Dec 2024 14:11:01 +0000 >> >> Eli Zaretskii writes: >> >> >> It might take a while for that to happen, which is why I still believe >> >> it would be better if tree-sitter major modes would populate >> >> `treesit-language-source-alist' on their own, and point to the specific >> >> checkouts that the major mode developer tested their implementation >> >> against. >> > >> > We could have done that, but there's no way we could keep the value of >> > treesit-language-source-alist up-to-date, because the grammar >> > libraries put out new versions much more frequently than Emacs >> > releases, especially if you consider libraries that have no official >> > versions at all (in which case we can only point to some revision in >> > their repository). >> >> Is there a reason we need to keep them *that* up to date? > > There is: later versions generally improve on older ones and fix some > bugs. I would hope that most releases are stable most of the time setting aside future changes to the language. Related to this, it might not be bad to have some way to keep an overview over updates to the grammars, and not just jump from one development tip to another. >> What happens when someone is on an older version of Emacs, and with >> Tree Sitter changes in the meantime the current development tip is >> not compatible with the library that Emacs binds against? It seems >> more reliable to me to pin what commit the grammar was tested >> against, if only as a hint. > > It's more reliable, but it could have the effect of keeping people > from upgrading when they can. What is better? I don't know. > >> > The question that bothers me is how useful is it to have >> > treesit-language-source-alist that is outdated? What do we expect the >> > users to do with such an outdated value? >> >> One idea is to first download the pinned version, and if that can't be >> built to download the tip. We could also prompt the user to check with >> them. > > If we do that, it is basically what we have today: the responsibility > for deciding which version to install is on the user. It should make it easier to install a specific release. >> If this is a serious issue (which I cannot estimate), we can provide an >> official package similar to the on MELPA with updated references. > > Yes, if we have volunteers to keep these up-to-date (which involves > testing the new versions when they come out). Which is why I think it would be best to tie this up with the -ts-modes by explicitly listing where and what grammar to fetch. But part of my premise is that outdated (but stable) is better than unstable (but newer). Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: Philip Kaludercic , rms@gnu.org, manphiz@gmail.com, >> emacs-devel@gnu.org >> Date: Fri, 27 Dec 2024 18:29:47 +0000 >> >> Eli Zaretskii writes: >> >> > We could have done that, but there's no way we could keep the value of >> > treesit-language-source-alist up-to-date, because the grammar >> > libraries put out new versions much more frequently than Emacs >> > releases, especially if you consider libraries that have no official >> > versions at all (in which case we can only point to some revision in >> > their repository). >> >> May this list be updated from ELPA? Via a special package or maybe via compat.el. > > Everything is possible, if someone volunteers to do the job. (There's > still the question I asked whether such a package will be useful and > used by enough users, but that is secondary.) > > In general, people are suggesting all kinds of semi-solutions for a > problem that has no solution, and isn't ours to solve to begin with. > I don't mind providing such semi-solutions, if someone volunteers, I'm > just pointing out their (almost obvious) downsides, so people would > not make a mistake of thinking we can solve this like we are used to > solve such problems when they are under our complete control. I also think that ELPA could help here. To make the semi-suggestion more concrete, if we went ahead and would specify the exact sources to use in each -ts-mode.el file, it would be easy to write a package that scraped emacs.git for these declarations and bundled them into a package. If there is no principle objection to these suggestions, I can write up a prototype.