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: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Date: Sat, 19 Nov 2022 13:36:16 +0200 Message-ID: <83pmdj89cf.fsf@gnu.org> References: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> <874juvhoyi.fsf@posteo.net> <83zgcn8i08.fsf@gnu.org> <87sfif43xq.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31392"; 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: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 19 12:36:35 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 1owM9C-00081j-BI for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Nov 2022 12:36:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owM8r-0002fN-9J; Sat, 19 Nov 2022 06:36:13 -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 1owM8q-0002fC-8A for emacs-devel@gnu.org; Sat, 19 Nov 2022 06:36:12 -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 1owM8p-0007tR-5w; Sat, 19 Nov 2022 06:36:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vnQIb7JHhQgsAZNQ8t2/8SUyL/6q8yCuN3W2uAjCDPw=; b=ro6d2eP59gFj wYRr+WcDw0sKWwYihZQRgNoo+EWSEl+l5gicXo3y1XR/KSxuUDl7FpzPssgFZF2/FVKgnY2NwjXPn JOPpabCsfP1cwJLghfh0ewFNltmlTVQp/tw5HXC9A66d2xbC+n3PwiD0n8FlKVUCQnkdMseAciKeA GGeGeN8s+W6VKWGIHb0feoNMciUK3kcdtC6P34zMti3oagmTMz6kSgvYyVrYboMNVn9psMC3NoGCY J9SSOkpImUTyRgh+Ovgb/qxEZQcMwtrXgQhnQtX+ApiKZ5WVJDf98sjLgpCbsKkzQE9TIVYntg5nU 8O+UztZE2O7XufecQnXldA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owM8o-0004wb-IL; Sat, 19 Nov 2022 06:36:10 -0500 In-Reply-To: <87sfif43xq.fsf@posteo.net> (message from Philip Kaludercic on Sat, 19 Nov 2022 10:46:41 +0000) 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:300157 Archived-At: > From: Philip Kaludercic > Cc: jostein@secure.kjonigsen.net, casouri@gmail.com, emacs-devel@gnu.org, > theo@thornhill.no, jostein@kjonigsen.net > Date: Sat, 19 Nov 2022 10:46:41 +0000 > > Eli Zaretskii writes: > > > 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. It depends, the decision should be on a case by case basis, IMO. For functionality that is part of what we want Emacs to have, yes, it should be distributed with Emacs. > 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. Emacs cannot come without support for important programming languages, that would make no sense. If we want to move towards tree-sitter as the basis for some aspects of such major modes, we must have this in core. Having such important parts of Emacs in ELPA when we don't have a way of bundling ELPA packages with an Emacs release tarball means a deficiency in released versions of Emacs, so we should not go that way. I don't see why what was done on the branch with introducing tree-sitter capabilities into major modes should be considered "experiments", let alone not "successful". What parts of that concretely do you think belong to these categories, and why? More generally, why should we be afraid of including new stuff in Emacs, and instead designate it "experimental" and put it on ELPA? We never did that in the past, and I don't see why would we want that now or in the future. ELPA is not a platform for "experiments" in Emacs development; the master branch and the feature branches are that platform. > >> 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. No, we should do that on feature branches, not on ELPA. Certainly so for changes that require changes on the C level. Again, ELPA is not a place where we should develop Emacs. > >> 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. What concretely isn't ripe? And please note that Emacs 29 won't be released tomorrow or the next week. We have the whole release cycle ahead of us to figure out what is not yet ripe for a release and either fix that or (in extreme cases) remove that from Emacs. I see no reason to make these decisions today. We used the feature branch for initial shakeup and stabilization, and we now think the tree-sitter support is mature enough to let more people use it and provide their feedback. > 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. If that was your reasoning, then I think you are three steps ahead of where we are, and you are trying to find solutions for problems that don't necessarily exist. We should see what concrete problems are left after the merge, and take it from there. We have ample time for figuring that out and fixing whatever will need fixing.