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: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Date: Sat, 19 Nov 2022 10:46:41 +0000 Message-ID: <87sfif43xq.fsf@posteo.net> References: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> <874juvhoyi.fsf@posteo.net> <83zgcn8i08.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2992"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jostein@secure.kjonigsen.net, casouri@gmail.com, emacs-devel@gnu.org, theo@thornhill.no, jostein@kjonigsen.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 19 11:47:33 2022 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 1owLNk-0000ad-F6 for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Nov 2022 11:47:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owLNB-0005jN-Ek; Sat, 19 Nov 2022 05:46:57 -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 1owLN1-0005fp-C0 for emacs-devel@gnu.org; Sat, 19 Nov 2022 05:46:48 -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 1owLMy-0002Wa-Fg for emacs-devel@gnu.org; Sat, 19 Nov 2022 05:46:47 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9CDA6240104 for ; Sat, 19 Nov 2022 11:46:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668854802; bh=XtGzzt0C9tKacGrjakgb1Pq7BTHuMDGLuCVkOSXj5RM=; h=From:To:Cc:Subject:Date:From; b=DS4F7wUZpNx06azTN8SHzyHZRmEeFy3ckCwn9DoDLBIX47+DSxLORKQG0fTmJKO4m MuMrh/FqYIzi4rXHITirGy6J72PXVLNKY7ATE6ZRXHQniH8IWkRY/92KUrAK1uJRdC Yxv8C5P/eSzMiTAa+OBN3sx7u5Q3zAxLKqDlJMyV5+cCOYizo8OcT+UddWG15TMjLV RTc55JjV1XIhL3GXxx33+eFMVTUnbsJkULTWIDBrkHQldm/LxENOO1X1uPG3QVaVQS loD751Ve53m9n4MOPHfdgjJY9vQA4gyGWd2IW3lDmRxWFqkpRyfXG09BXGiQKQ+NZZ VRjyixyXNTsmg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NDr1X56Hbz6tn9; Sat, 19 Nov 2022 11:46:40 +0100 (CET) In-Reply-To: <83zgcn8i08.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Nov 2022 10:29:11 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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:300150 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: Yuan Fu , emacs-devel , >> Theodor Thornhill , Eli Zaretskii , >> jostein@kjonigsen.net >> Date: Fri, 18 Nov 2022 22:34:13 +0000 >>=20 >> Jostein Kj=C3=B8nigsen writes: >>=20 >> > Instead of waiting for "every" major-mode to be re-implemented into a >> > tree-sitter derivative in the feature/tree-sitter branch before we >> > merge... How about we just accept the current "core" tree-sitter >> > implementation as good enough, and consider merging that to git master >> > as is. >>=20 >> I think this sounds like a good idea -- as someone who has mostly just >> been following the discussions. The core bindings and major modes that >> are based on these are separate issues, with a clear dependency linked >> them. > > From where I stand, it makes very little sense to release Emacs 29 > with tree-sitter support that is limited to primitives and some > minimal Lisp glue on top of that. Tree-sitter was added to Emacs to > allow major modes provide better support for editing program source > code, so having tree-sitter "support" in Emacs 29 that didn't include > at least several major modes using it would be disappointing at best. > It would mean we ourselves have no idea how to make major modes use > the feature. Moreover, adding those few major modes on the branch > exposed several deficiencies in the original design and > implementation, and required changes to make the integration better; > releasing Emacs 29 with those issues unresolved (and unknown) would > require significant, sometimes incompatible changes in the future, > which is another reason why it would be wrong. > > Basically, my firm belief is that adding to Emacs infrastructure > without user-level applications built on that infrastructure is wrong > and runs the risk of producing features that are not used or need deep > surgery before they become useful. We should avoid doing that as much > as possible. My question is, do these user-level applications have to be distributed along with Emacs, or could they be made to be "explicitly" opt-in by installing them from ELPA. In-core appears to usually bring a commitment to maintain a library, and deprecating can take years. If Emacs 29 lays the technical foundations, the low-level API for treesitter to work, we can have packages on ELPA experiment with the higher-level abstractions. Whatever is the most successful approach, can be added to Emacs later on. >> As an aside: This might also be a good opportunity to clean up some of >> the current major mode implementations and make them more consistent. >> The issue with custom options to enable tree-sitter for every major mode >> has revealed an inherent duplication of features. There are other >> inconsistencies, especially regarding bindings for equivalent operations >> (e.g. in interpreted language with a repl, how to load function into the >> current session: Lisp, Prolog, Python all differ in minor details). > > Cleaning up major modes is a Good Thing that needs no opportunities. > We should do that whenever we know and agree how. Fair enough, but just as above I think these kinds of experiments are better made outside of the core, in ELPA, to avoid committing to mistakes. If it works out, it can be added. >> The current branch has major modes, should these be deleted before >> merging? > > Definitely not! These modes are there because we want Emacs 29 to > have them, and we want users to use them and report back. IIUC these modes aren't ripe yet, or at least aren't satisfying replacements for the existing modes. If tree-sitter were not to be merged for that reason, that would delay the ability to use tree-sitter on a widespread basis for at least another release. My proposal above would make it possible, and encourage users to report on their experience, while allowing for the flexibility to make the right decisions in the long term.