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: Re: Call for volunteers: add tree-sitter support to major modes Date: Tue, 11 Oct 2022 08:58:00 +0200 Message-ID: References: <83czb1jrm3.fsf@gnu.org> <878rlo7on0.fsf@thornhill.no> <83o7uki5ol.fsf@gnu.org> <87tu4c5g9j.fsf@thornhill.no> <835ygshz6k.fsf@gnu.org> <87zge3jj0j.fsf@gnus.org> <83o7uig9dm.fsf@gnu.org> <9E2D0EEB-3910-4C58-96E7-68E7C84E5097@thornhill.no> Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------skURQd0bW3NxHQGhUWzQ7kDi" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33075"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Cc: acm@muc.de, emacs-devel@gnu.org, jostein@kjonigsen.net To: Theodor Thornhill , Eli Zaretskii , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 09:05:45 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 1oi9Kh-0008PV-W2 for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:05:45 +0200 Original-Received: from localhost ([::1]:49384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oi9Kg-0008Qj-OD for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 03:05:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35840) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi9DP-0005Ch-9I for emacs-devel@gnu.org; Tue, 11 Oct 2022 02:58:13 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:40889) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi9DM-0005nH-95; Tue, 11 Oct 2022 02:58:11 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9E62F320046E; Tue, 11 Oct 2022 02:58:03 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 11 Oct 2022 02:58:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc: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=fm2; t= 1665471483; x=1665557883; bh=DHQwaAhADALjwKYdhWMixKXjJ3iio8x3xpj GSwxpIxI=; b=e5EEwMXd1T0TvFS5hceuslHDSrk0TRFOg8AkgRxMPaTb+5RLk/h BpSdizc/ymy5CSlobYZXtqZMZj0M6wZzavIBgo/0i0KZYXYg92PnUhyplL1ZDZry XW8uab2kc+rCyFEa12HWOe1CA3LJx7weqtY7wNkB41nEZUHB6MIK9PIPyfgtvx4g SPPhFYehJ9h/2Mb9UvJPuph2g5KXYNfu4EXRueb7dBJ2HuBij7/uUafru/4Iu4Ea wbqQKnZQGPjhRoXvPizs/NgaJNycjOGbTtsLnJwdttr3Nr7zgicvkbhuGAwACblQ /fcdiIWmI7ztqSKhlxE5O5N1cu3TXY/+Grg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; t=1665471483; x=1665557883; bh=DHQwaAhADALjw KYdhWMixKXjJ3iio8x3xpjGSwxpIxI=; b=A+HdDIMq6iD04WKmTMWp6wDAbHhLC T6t4pV6BFxe1trgVo+ZE1eMJYnMZCOLt1JjgPgBVEqFGSsfs2FoxHhcNl13fUuVC LjcgQ66Gcm171gXd6s0olFT4mXICxpQokCYYUSmv4KgMFL3vTae9MNJv9S5WzNsQ bxGNWLIammKJ6NBZWSfqiHCs/4qsGB86Lw9fQHm9K5ZnXTuKkAXgjwpsjcuC2Cqz uVnvAFvLcwCUEUBYdmS4dIxxEr/y6lTfF1+hyH5GhZm0XAjwQ6lxySvy4wYGZCLA 72tQP3WSLvo1cEgmdeQeiKqV4d+d3Zz1Xp1kbuNIGX/kzCHf7zdr7ULwA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejhedgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtkfffgggfrhfuvfevfhfhjgesrgdtreertdefjeenucfhrhhomheplfho shhtvghinhgpmfhjpphnihhgshgvnhcuoehjohhsthgvihhnsehsvggtuhhrvgdrkhhjoh hnihhgshgvnhdrnhgvtheqnecuggftrfgrthhtvghrnhepheffteffjefgtefglefhgedt jeehieekjeffjefgheejheeffefgvdevteetveehnecuffhomhgrihhnpehkjhhnihhgsh gvnhdrnhhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepjhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhighhsvghnrdhnvght X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Oct 2022 02:58:02 -0400 (EDT) Content-Language: nb-NO In-Reply-To: <9E2D0EEB-3910-4C58-96E7-68E7C84E5097@thornhill.no> Received-SPF: pass client-ip=64.147.123.20; envelope-from=jostein@secure.kjonigsen.net; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.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, NICE_REPLY_A=-2.007, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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" Xref: news.gmane.io gmane.emacs.devel:297430 Archived-At: This is a multi-part message in MIME format. --------------skURQd0bW3NxHQGhUWzQ7kDi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit If someone has typescript-mode installed from MELPA and upgrade to Emacs-29... Which typescript-mode are they going to be running? Emacs does not support namespaces, so there would be no way to separate those two. And if the MELPA version runs, it would shadow the Emacs29 implementation. Since I believe in keeping things simple for users, I think another option we could consider would be to simply make typescript-mode (the plain elisp version hosted on MELPA) simply not register itself if it finds that the tree-sitter version is already available from Emacs. And then we could stop updating it, and people would eventually stop installing it. Speaking as one of the MELPA typescript-mode co-maintainers, I have absolutely zero plans for maintaining the old elisp-based version once a better, tree-sitter version has been mainlined into Emacs itself. -- Jostein On 11.10.2022 08:41, Theodor Thornhill wrote: > > On 11 October 2022 08:30:29 CEST, Eli Zaretskii wrote: >>> From: Lars Ingebrigtsen >>> Cc: Theodor Thornhill,acm@muc.de, >>> emacs-devel@gnu.org,jostein@kjonigsen.net >>> Date: Tue, 11 Oct 2022 02:34:04 +0200 >>> >>> Eli Zaretskii writes: >>> >>>>> My suggestion is to add the tree-sitter variant in these cases, and let >>>>> the other modes die a slow, deprecated death down the line. >>>>> >>>>> What do you think? >>>> SGTM, but I'd like to hear from Lars as well. >>> It's somewhat confusing that we have some modes that are tree-sitter-only >>> and some what can switch between using tree-sitter and not, but I guess >>> that's inevitable. >> We could arrange for a very minimal font-lock without tree-sitter >> (like, for example, only strings and comments?), and use the defaults >> for the indentation commands. Theodor, can that be done with a >> relatively small effort? > Yes, we could actually just delegate that work to vanilla js-mode, as Typescript is just a superset of Javascript. That would mean we would get the benefits of that lineage, but missing some more advanced highlights etc. > > What do you think? > >>> But I think the in-tree tree-sitter typescript-mode will have to be >>> called something else than the out-of-tree non-tree-sitter one, at >>> least. >> That's desirable, yes. > Sure, I can rename it to tsx-mode, because that's the parser being used. Why is that desirable, though? > > Theodor -- Vennlig hilsen *Jostein Kjønigsen* jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjønigsen.no --------------skURQd0bW3NxHQGhUWzQ7kDi Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

If someone has typescript-mode installed from MELPA and upgrade to Emacs-29... Which typescript-mode are they going to be running?

Emacs does not support namespaces, so there would be no way to separate those two. And if the MELPA version runs, it would shadow the Emacs29 implementation.

Since I believe in keeping things simple for users, I think another option we could consider would be to simply make typescript-mode (the plain elisp version hosted on MELPA) simply not register itself if it finds that the tree-sitter version is already available from Emacs. And then we could stop updating it, and people would eventually stop installing it.

Speaking as one of the MELPA typescript-mode co-maintainers, I have absolutely zero plans for maintaining the old elisp-based version once a better, tree-sitter version has been mainlined into Emacs itself.

--

Jostein

On 11.10.2022 08:41, Theodor Thornhill wrote:

On 11 October 2022 08:30:29 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
From: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Theodor Thornhill <theo@thornhill.no>,  acm@muc.de,
  emacs-devel@gnu.org,  jostein@kjonigsen.net
Date: Tue, 11 Oct 2022 02:34:04 +0200

Eli Zaretskii <eliz@gnu.org> writes:

My suggestion is to add the tree-sitter variant in these cases, and let
the other modes die a slow, deprecated death down the line.

What do you think?
SGTM, but I'd like to hear from Lars as well.
It's somewhat confusing that we have some modes that are tree-sitter-only
and some what can switch between using tree-sitter and not, but I guess
that's inevitable.
We could arrange for a very minimal font-lock without tree-sitter
(like, for example, only strings and comments?), and use the defaults
for the indentation commands.  Theodor, can that be done with a
relatively small effort?
Yes, we could actually just delegate that work to vanilla js-mode, as Typescript is just a superset of Javascript. That would mean we would get the benefits of that lineage, but missing some more advanced highlights etc. 

What do you think? 


        
But I think the in-tree tree-sitter typescript-mode will have to be
called something else than the out-of-tree non-tree-sitter one, at
least.
That's desirable, yes.
Sure, I can rename it to tsx-mode, because that's the parser being used. Why is that desirable, though? 

Theodor 
--------------skURQd0bW3NxHQGhUWzQ7kDi--