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 10:16:32 +0200 Message-ID: <831qpz9x5r.fsf@gnu.org> References: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> 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="22630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, theo@thornhill.no To: jostein@kjonigsen.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 19 09:17:22 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 1owJ2Q-0005cI-1n for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Nov 2022 09:17:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owJ1m-0001Ln-Bb; Sat, 19 Nov 2022 03:16: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 1owJ1a-0001LP-8k for emacs-devel@gnu.org; Sat, 19 Nov 2022 03:16:32 -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 1owJ1Z-00089w-0i; Sat, 19 Nov 2022 03:16:29 -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=hKAvwraDKXv9dEqn25V3N/5ArnPNsBvFqLd8anCqHvI=; b=VhLKmoVvNSia2jumvGYN SFVyKzoMhFTxRB1d/0nmDIlUdKnojubknD5RyM4rA2URSHNCd55Q7dTug6YCM43m1HsltqZvvrTQk QIhfEwyLwGu+gFuUeWGFqf0fhJE7inOot5Wn0LpmVrAqvVogRp4MNS0tba/I3LTZdofqGfZCZv8c5 6QEZgvWXnZepPbR/F7G3gV/kaAWMSWpp/XCoiefSg9hg3I2J+pqw8MGVw7NxRiQtmvdnRWkyRWdcl r+KQScMAlIgGCyjESPjkrDhCkmTz9+gLTymjtYfq+lF8YnyAxtknVZ04Z1djn4F5tgqaSMmf3I9gj YzLuyDf8R+bD5Q==; 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 1owJ1X-0002wj-Nh; Sat, 19 Nov 2022 03:16:28 -0500 In-Reply-To: (message from Jostein =?utf-8?Q?Kj=C3=B8nigsen?= on Fri, 18 Nov 2022 22:54:49 +0100) 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:300142 Archived-At: > Date: Fri, 18 Nov 2022 22:54:49 +0100 > From: Jostein Kjønigsen > > I know this has been said before, by people which by far has been contributing much more than me... But I > still don't think it's a good idea to replace the implementation in existing major-modes with tree-sitter > implementations, nor selectively activate tree-sitter in major-modes prone to inhetitence and derivation. > > Me and Theodor faced these same issues with "our" C# and TypeScript major-modes, and the only "clean" > way we agreed we could make this work was to create wholly new implementations. I can come up with > many good, objective reasons for this, but I think Theodor has already represented this view fairly well. > > While for the sake of brevity, I'll not diving deeply into this particular thing, I will say this: A new tree-sitter > based major-mode free of compatibility concerns allowed us to create entirely new major-modes fixing most > of our existing bugs, faster than we before would be able to fix a single bug. My personal view is that mixing > existing major-modes with tree-sitter represents absolutely the worst of all worlds. It maintains all existing > complexities, provides us with very few benefits, and at the same time adds complexities we didn't use to > have. To me, that's a net negative. > > Somewhat surprising to me, I see this is a somewhat controversial point of view and not as clear cut a > matter as I would have expected it to be. I realize and respect that final decisions in these matter might take > some time to mature. Time which given our current approach detracts from the momentum tree-sitter has > been having. You are looking at this from the POV of developing these features. But we have another vantage point to consider: that of our users. >From their POV, we cannot replace existing modes with completely new and separate implementations, we must provide a migration path which will allow users to decide when and whether they want to switch to the tree-sitter based implementation. This will also allow us to improve the tree-sitter support of the modes by collecting user feedback sooner rather than later. So we decided to have a hybrid approach: in some modes to provide separate implementations, and in others to provide optional features that users can selectively switch on. > 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. Here you are preaching to the choir, since the decision to merge soon was already made. And it cannot be otherwise, since the time of cutting the emacs-29 release branch is closing up, and we said 2 months ago that we intend to release Emacs 29 with tree-sitter support.