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 16:47:33 +0000 Message-ID: <87y0zviyu2.fsf@posteo.net> 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> <87plldrx6a.fsf@posteo.net> <87ikr5rwx0.fsf@posteo.net> <904957B9-55C1-42DF-BE6A-16986A4B539A@dancol.org> <87r05o2eji.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12009"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Emacs-devel@gnu.org" To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 17:48:27 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 1tSfPt-0002zi-TZ for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 17:48:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSfPG-00012i-Nm; Tue, 31 Dec 2024 11:47:46 -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 1tSfPB-00012W-2J for Emacs-devel@gnu.org; Tue, 31 Dec 2024 11:47:42 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSfP8-0006OE-Vj for Emacs-devel@gnu.org; Tue, 31 Dec 2024 11:47:40 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8E637240103 for ; Tue, 31 Dec 2024 17:47:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735663656; bh=LpYudnvJ3/Ijo295E7BVf/383BUL8sHyeOSDpaOEVCk=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=Yr8dbtZkvHhpGuyZkN1oqydZSolO9Nr7YJyT7icwnwNazgKE6atDaV2UD/AUK7K3c OrvBa3b3X6ywQEKJHUnhh3ExxipuAI/MOmrR4iJxTFK9vrDcTwlJQCDNJKRNxFJFE/ 5apvXGBTRH4+pPHJr/Y4dBSbsH+0hyxkVNXAuLr1sMGL00MAoo8X88cFtODcrdIBOl OtFPV8mtW8UhzbYbxRyG9CG+Tuwf46zENoBDe6SJKjIbM2gToO9/ysHt4Th1hdhQSL FygSoHlTx0bo/U8XXAkjFLS+Owt8PMJkmghfk1ZEP9FrceXMpCkgbtE/buvCGqzaA7 rBDbvNy/PCyaA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YMzRB35TXz9rxB; Tue, 31 Dec 2024 17:47:34 +0100 (CET) In-Reply-To: (Daniel Colascione's message of "Tue, 31 Dec 2024 08:57:18 -0500") 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.66; envelope-from=philipk@posteo.net; helo=mout02.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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:327534 Archived-At: [Re-adding Emacs-Devel] Daniel Colascione writes: > On December 31, 2024 8:00:17 AM EST, Philip Kaludercic wrote: >>Daniel Colascione writes: >> >>[...] >> >>>>> There is also the general point of helping to realise software freedom, >>>>> where a -ts-mode makes it much more difficult (though of course not >>>>> impossible) to adjust a grammar. Wasn't there some complication when >>>>> trying to reload a grammar? The additional dependencies and the >>>>> indirect effect of changes compared with Elisp is something we should be >>>>> concerned about when trying to maintain "the spirit of Emacs" (which of >>>>> course means different things to different people). >>>>> >>>>> Vendoring might help to reproduce builds if that turns out to be a big >>>>> issue, but I am not a fan of the additional hurdles in making use of the >>>>> source code. Does anyone know of alternative, less invested >>>>> build-chain the re-uses the libtree-sitter.so library. >>>> >>>>Oh, and another point I have been reminded of while writing this: The >>>>recent addition of more and more -ts-modes without "regular" -modes has >>>>been slightly concerning. While I understand that re-implementing a >>>>"lua-mode" or "php-mode" from scratch is not an effort one wants to >>>>impose on anymore, simpler files such as dockerfile-mode or go-mod-mode >>>>/without/ Tree Sitter would be a nice thing to have for people on >>>>systems without Tree Sitter, or without the ability to download and >>>>build code from GitHub (e.g. missing internet access, without Git/GCC, >>>>without the necessary development libraries). Even if the experience >>>>were degraded, just re-using the keywords to provide some basic >>>>highlighting would be a nice fallback. >>> >>> I think it's inevitable that, long term, tree sitter becomes a >>> mandatory dependency and we delete the bespoke Emacs modes. It just >>> doesn't make sense to replicate per-language work the community is >>> already doing. There's no economic or software freedom benefit in >>> doing so. >> >>As long as (live-)modifying a Tree Sitter grammar is significantly more >>difficult than with the regular major modes, I think that -ts-modes have >>a significant advantage -- especially for Emacs. > > You meant non-ts? No, I meant that modifying the grammar of a -ts-mode is more difficult, as changes to the JS files requires a special toolchain and IIUC cannot be reloaded inside of Emacs. Or am I wrong? > Anyway, I've already described ways to make modify > TS easy. (For example, not introducing unnecessary complexity to the > distribution process.) It'd be better to make TS customization easy > than redundantly write and maintain TS and non-TS modes under the > theory that the latter can be more easily customized. I haven't been able to follow the mailing list for the past few days, I would appreciate i you could give me the message ID where you elaborated on this. >>> If we try, we'll just confuse users and ship modes that fall >>> further and further behind those of other systems. >> >>Ideally, it should have been possible to hide the difference between >>tree sitter and non-tree sitter modes. From what I understand that was >>not possible with the existing framework. After all, most of the time >>if tree sitter works, you don't notice it directly. I *do* notice it if >>something doesn't work as expected (e.g. `mark-sexp' not selecting the >>right regions is something that has been a deal breaker for me). > > That's not my ideal. To clarify, I meant that ideally the user shouldn't notice Tree Sitter, not the implementer. If everything works, it just improves indentation, structural navigation, syntax highlighting, etc. These are the effects of tree sitter, not tree sitter itself. This is different from other editor-generic systems like LSP, as Eglot exposes some functionality that people use directly, such as eglot-rename or eglot-code-actions. > Making modes work with or without tree sitter would involve doing a > lot of hairy language specific work twice, once to work with TS and > once without. This duplication of effort just doesn't make any sense > to me. How is anyone better off for having done this redundant work > instead of something else? Most of the time, the non-TS modes already exist and have accumulated a lot of functionality over time: REPL support, integration with Flymake, Eldoc, CAPF, custom user options, etc. What irks me about some of the new -ts-modes is that they provide a significant degradation in these aspects for now. We have to replicate all of this for -ts-modes. > Even if we could: why confuse users with a choice they're not prepared > to make? Why distract them with the difference between TS and non-TS > (which I'll start calling "legacy modes", come to think of it)? Simple > is better, especially for users. I agree that it would be better if we could hide the distinction. But tree sitter modes are not in a position to replace the traditional modes right now. Especially if using them at all requires fetching source code from GitHub. One thing one can do remedy the concrete problem that we have -ts-modes without corresponding non-ts-modes is to fall back onto `define-generic-mode' and at least provide some basic syntax highlighting for keywords -- which all -ts-modes have to declare anyway. That way languages like dockerfile(-ts)-mode or go-mod(-ts)-mode would at least do something, given that the information is already there.