From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jostein_Kj=c3=b8nigsen?= Newsgroups: gmane.emacs.devel Subject: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Date: Fri, 18 Nov 2022 22:54:49 +0100 Message-ID: References: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------l3n0cxtOKFBECVfo06jDpjFX" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8544"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 To: Yuan Fu , emacs-devel , Theodor Thornhill , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 18 22:55:58 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 1ow9L2-0001yo-DH for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Nov 2022 22:55:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ow9KC-0005Dt-RG; Fri, 18 Nov 2022 16:55:04 -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 1ow9KA-0005DV-Fe for emacs-devel@gnu.org; Fri, 18 Nov 2022 16:55:02 -0500 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ow9K3-0005zO-SY; Fri, 18 Nov 2022 16:55:02 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E84EA32006F2; Fri, 18 Nov 2022 16:54:51 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 18 Nov 2022 16:54:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm3; t= 1668808491; x=1668894891; bh=Rgnnbv0HIki9vuurWKeBnvVIvoXlIFgE4QR MDU8cYrY=; b=D+VrV9Y9ZPrGNDZ27qpiR6L9TSu+vs8B6i5stELwwWoNw/QEKx6 XaArdjzbuLBMRTV1wAO/vb7Za5o/u5gF57r3ar2js+CFgNH10qZlLKHnw/Jd7vvM bb7O/fHxcYsjOC3qutfoSR58efen72/a8VIy1jOSEU9RHTR4VBdpwF8ukzhtCfm/ 4TmPjz3o7tmsAbYCLIbyiAUA8B3Gi79jyP+EaRM/RK5DBmVoWpihOeFpQQvop316 a0xqDI7JLQIl4XcxFAcXRxtqpNc19ffmNExtj3/Bj8FQpmLZmZq+7FWzNiUVCLP6 IhDsdogghLEekgbaLFCekEY/z/WTpiyf7UA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1668808491; x=1668894891; bh=Rgnnbv0HIki9v uurWKeBnvVIvoXlIFgE4QRMDU8cYrY=; b=F3JNqB1qqpOzNkrebLz55CuS3KoA3 pqmTd8vwefsy/QK/8payuy5rxQ79IdIXkdhK4njHxOn9DdWc27yXKqMm2Cs7lG20 JsXuAt3bEZD9Dwic417/cOluxGyiWYWc4H3R8Xbe0Q9DxQWEnVhkY2fz4ySYeSO+ EJzJ+NjHtk3DlNYiGm1JzwBuX66ryjELUVHHykXYAYbSN4tooKh1anV2BSpxcseE pNf5Di4COoWTsu4Sk9HhQ2HX/CeEURt5lrYaFsDdnonBzyNtDQ0I9lstrWlJo5sS gztvWfNLj0k/wEizUHUUFRTCBpzxBB+nfDXw4mf4ztA1MBBin/ZExg+Rw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrhedtgdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfghruffvfhfhjgesrgdtreertdefjeenucfhrhhomheplfhoshht vghinhcumfhjpphnihhgshgvnhcuoehjohhsthgvihhnsehsvggtuhhrvgdrkhhjohhnih hgshgvnhdrnhgvtheqnecuggftrfgrthhtvghrnhepvdefuefhhfdvgfdtheeijedvheel jeeuleejhefhtdfhteffveduudfgheegjeelnecuffhomhgrihhnpehkjhhnihhgshgvnh drnhhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep jhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhighhsvghnrdhnvght X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Nov 2022 16:54:50 -0500 (EST) Content-Language: nb-NO, en-GB In-Reply-To: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> Received-SPF: pass client-ip=64.147.123.24; envelope-from=jostein@secure.kjonigsen.net; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 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:300124 Archived-At: This is a multi-part message in MIME format. --------------l3n0cxtOKFBECVfo06jDpjFX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey everyone. 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. At this point poor Yuan Fu here has spent quite a bit of time and effort getting a core tree-sitter interface into Emacs. I would really hate to see all that effort be for nothing, because we end up conflating a creating a core tree-sitter feature with how this feature should best be employed in subsequent major-modes. So in the name of pragmatism, I propose a compromise of sorts. 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. This will allow us to land one important mile-stone, while giving us the head-room to further discuss how we should best implement/reimplement/"upgrade" existing major-modes to take advantage of tree-sitter. It will also allow third-party packages to make use of tree-sitter in Emacs core instead coming up with its own implementation, beginning a defacto standardization of this new API (which I may note already has a competing implementation in MELPA). That is to say: We should land the core library, with holding it hostage to all its possible consumers being implemented. How about it? Are there any good arguments for NOT merging feature/tree-sitter at this point? :) -- Kind regards *Jostein Kjønigsen* jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjønigsen.no On 16.11.2022 21:45, Yuan Fu wrote: > So I’m trying to merge css-ts-mode with css-mode. Scss-mode inherits css-mode, but if user enables tree-sitter for css-mode, scss-mode will inherit all that tree-sitter setup, and lose all the native css setup. Then if a user doesn’t want to enable tree-sitter in scss-mode, too bad: scss-mode breaks. > > Essentially scss-mode needs to be able to control which parts of css-mode’s setup it wants to inherit—native setup or tree-sitter setup—regardless of whether css-mode enables tree-sitter or not. > > I wonder if we can do something like this: > > css-mode > | > +---------+-----+-----------+ > | | | > css-native-mode css-ts-mode scss-mode > | > +----+------------+ > | | > scss-native-mode scss-ts-mode > > css-mode: a virtual mode, only sets up basic things that both native and tree-sitter mode needs, like comment-start. > css-native-mode: native setup > css-ts-mode: tree-sitter setup > > scss-mode: a virtual mode, inherits css-mode > scss-native-mode: native setup > scss-ts-mode: tree-sitter setup > > And user could use major-mode-remap-alist to choose which mode they want: > > (css-mode . css-ts-mode) for enabling tree-sitter > (css-mode . css-native-mode) for not enabling tree-sitter > > This could also used for other modes, like c-mode: c-mode, c-native-mode (cc-mode), c-ts-mode. > > Yuan --------------l3n0cxtOKFBECVfo06jDpjFX Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hey everyone.

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.

At this point poor Yuan Fu here has spent quite a bit of time and effort getting a core tree-sitter interface into Emacs. I would really hate to see all that effort be for nothing, because we end up conflating a creating a core tree-sitter feature with how this feature should best be employed in subsequent major-modes.

So in the name of pragmatism, I propose a compromise of sorts.

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.

This will allow us to land one important mile-stone, while giving us the head-room to further discuss how we should best implement/reimplement/"upgrade" existing major-modes to take advantage of tree-sitter.

It will also allow third-party packages to make use of tree-sitter in Emacs core instead coming up with its own implementation, beginning a defacto standardization of this new API (which I may note already has a competing implementation in MELPA).

That is to say: We should land the core library, with holding it hostage to all its possible consumers being implemented.

How about it? Are there any good arguments for NOT merging feature/tree-sitter at this point? :)

--
Kind regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no
On 16.11.2022 21:45, Yuan Fu wrote:
So I’m trying to merge css-ts-mode with css-mode. Scss-mode inherits css-mode, but if user enables tree-sitter for css-mode, scss-mode will inherit all that tree-sitter setup, and lose all the native css setup. Then if a user doesn’t want to enable tree-sitter in scss-mode, too bad: scss-mode breaks.

Essentially scss-mode needs to be able to control which parts of css-mode’s setup it wants to inherit—native setup or tree-sitter setup—regardless of whether css-mode enables tree-sitter or not.

I wonder if we can do something like this:

             css-mode
                 |
       +---------+-----+-----------+
       |               |           |
css-native-mode   css-ts-mode  scss-mode
                                   |
                              +----+------------+
                              |                 |
                        scss-native-mode   scss-ts-mode

css-mode: a virtual mode, only sets up basic things that both native and tree-sitter mode needs, like comment-start.
css-native-mode: native setup
css-ts-mode: tree-sitter setup

scss-mode: a virtual mode, inherits css-mode
scss-native-mode: native setup
scss-ts-mode: tree-sitter setup

And user could use major-mode-remap-alist to choose which mode they want:

(css-mode . css-ts-mode) for enabling tree-sitter
(css-mode . css-native-mode) for not enabling tree-sitter

This could also used for other modes, like c-mode: c-mode, c-native-mode (cc-mode), c-ts-mode.

Yuan
--------------l3n0cxtOKFBECVfo06jDpjFX--