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: Average-user-facing interface for tree-sitter Date: Thu, 13 Oct 2022 16:32:37 +0200 Message-ID: References: <3A7E7CD1-74A7-4352-9DFE-FC982EAA398E@gmail.com> <87ilko9r9e.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------PCeQltbIFMI4jvSGrSPg01cO" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29191"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: emacs-devel To: Lars Ingebrigtsen , Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 13 16:34:38 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 1oizID-0007Jr-Gu for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 16:34:38 +0200 Original-Received: from localhost ([::1]:42924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oizIC-0004sz-Bd for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 10:34:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oizGR-0002nO-KR for emacs-devel@gnu.org; Thu, 13 Oct 2022 10:32:50 -0400 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:52849) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oizGO-0002qk-UO for emacs-devel@gnu.org; Thu, 13 Oct 2022 10:32:47 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D345032003CE; Thu, 13 Oct 2022 10:32:40 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 13 Oct 2022 10:32:41 -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:sender:subject:subject:to:to; s=fm2; t=1665671560; x= 1665757960; bh=ZdsV/aGkaoZD2/UyWDNO6t1ianR8/2fxGh7CsWGiS9A=; b=S eQPZyUg3wTx4/dWQQtnAdXZ4e7oaMBxTB88gfVcuW0HR0PEX0QwHrt/5ONsxSJ2w VlTPXt2o6A0YHpw3dwryM/OaEI0odPWkM9N29dVMM1pHx3OW9851D394Y9LA2HdS +rE7a/E9CoA6YT6+y2Z0WoJy2eeHFqt4OHbDVPfPowylkOzPC0PnQXBi8SQeZLKM 9fDZTIZpHzcOHQJEIZiM/dO/hR94TZv1wo1/D49pkF2sMdFL4JD/08OwA9K80QDZ EdBQ4ehJivsdh06MQkIQ977+p3eGfM6V7QzvjlDY+4BDN2Vdxzu/UURJtF9XBAuJ wJM81AaZBwn/GWBjPP+Fw== 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:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1665671560; x=1665757960; bh=ZdsV/aGkaoZD2/UyWDNO6t1ianR8 /2fxGh7CsWGiS9A=; b=uHkIpu5dyTiovOyvnuX7q3T6EgNYtxA58eWFfnKWMdUE F2HreYxI5D3fqnIHxhmyrkctHG13Ax9aZoOrHDRhbs8CFtZA9zmiQ9hNQq7CwXsT 63mjX0nIwzBSZrA0nr1wZ7hGxVNKS9iXw2LCiT+XyQrGLNIQlrB7D1pvjpBMsm9a MfoPNK2MBYMAmKrsaTJyXAVhDdqG3pqr5ypumHqo+HONv4b/y6wGxyOHfj7nGib7 XLJ2qzYpjmfBmfI0PAhPpGcdorJlK1wAU6++N/sroy3hBnX0+zFJOb3EMfohMo6+ TNYe6MEcdQGNUvVLVSrZXzSDyiN6FdjNeozy0iDiNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeektddgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfevfhfhjgesrgdtreertdefjeenucfhrhhomheplfhoshht vghinhgpmfhjpphnihhgshgvnhcuoehjohhsthgvihhnsehsvggtuhhrvgdrkhhjohhnih hgshgvnhdrnhgvtheqnecuggftrfgrthhtvghrnhepuedvgfegfeekteegfeetkefhhedu gfelgfefhffgfefghfdvjeefheevvedukeefnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepjhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhi ghhsvghnrdhnvght X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Oct 2022 10:32:39 -0400 (EDT) Content-Language: en-US In-Reply-To: <87ilko9r9e.fsf@gnus.org> Received-SPF: pass client-ip=64.147.123.19; envelope-from=jostein@secure.kjonigsen.net; helo=wout3-smtp.messagingengine.com X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 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=-1.25, 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:297679 Archived-At: This is a multi-part message in MIME format. --------------PCeQltbIFMI4jvSGrSPg01cO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Yuan Fu writes: > >> From the suggestions I collected from the old thread, here is my proposal: >> >> We define a custom option treesit-settings (we can discuss the name >> later), which controls whether to enable/disable tree-sitter for each >> major mode, and the default preference, like this: >> >> (defcustom treesit-settings '((t nil nil)) >> "Tree-sitter toggles for major modes. > Hm... well, there's also modes that are "pure treesit", and there are > (or will be) alternate modes with and without tree-sitter. > > I think users basically fall into two camps: The ones that want to have > tree-sitter in all modes, and ones that want to enable it in specific > modes (and ones that don't want it at all). (Note Computer > Science-mandated off-by-one error.) > > This suggests to me that we should just use the normal minor mode > machinery that we have for these things. > > That is, people that want treesit in python-mode will say: > > (add-hook 'python-mode 'treesit-mode) > > And people that want it everywhere will say: > > (global-treesit-mode) > > This mode will, in addition to switching `treesit-mode' on everywhere, > also set up `major-mode-remap-alist', so that `typescript-mode' is > mapped to `ts-mode', and `c-mode' is mapped to `treesit-c-mode' (which > I'm sure somebody is going to write in a couple of days), etc. > > Hey there. I'd like to come up with a somewhat contrarian point of view, if nothing else to provide a point of reference. Right now we have a single (that is: one, 1) implementation for c-mode and c++-mode. They are based on cc-mode. There's no c-mode where you enable usage of cc-mode through a minor-mode, nor is there a global-cc-mode toggle. And there's a really simple reason for that. That's because c-mode is implemented using cc-mode as a foundation, and there's no other implementations. Now if we are starting to implement some new major-modes using treesitter as a foundation (for instance ts-mode or c#-mode), such a toggle for tree-sitter-mode will be equally pointless. There is no ts-mode without treesitter. And what should we do if people activate ts-mode without these bespoke minor-modes being active at the same time? I think it's a bit fuzzy and doesn't really sound very .. well defined. Existing users of typescript-mode can be guided to the new implementation through a variety of ways, but to me the flow of activating typescript-mode major-mode, then treesit-minor-mode, and then magically switching to ts-mode makes absolutely no sense. And the performance of that is probably terrible too. For those users I think a simple deprecation warning which informs about the new built-in ts-mode should be more than sufficient, for the users to clean out the old (buggy) typescript.el from their conigs. The one place where it gets slightly complicated is for major-modes where one decides to have two or more canonical implementations, that is to add a new treesitter backend alongside the existing elisp-one. For an established built in-mode, like c-mode, switching over night is probable not feasable nor desirable. So in practice you will have a few modes where you might have multiple backends, ideally only in a transitional phase, but in worst case scenario permanently. So how can we deal with /that/ problem, where we have it, and not everywhere else? I've had a similar "problem" for LSP backend for some programming languages. The solution I landed on there was to have a defcustom per language/major-mode where there were different LSP-backends which I may want to use. Examples below: - (defcustom csharp-lsp-backend) ;; 'lsp-mode 'omnisharp - (defcustom typescript-lsp-backend) ;; 'lsp-mode 'tide Then I in my major-mode hooks checked for which of the possible backends are chosen and dynamically dispatch based on that. For major-modes ending up with multiple backends, I think this is an approach which scales better (supports more than 1 backend, but only 1 at a time!), and will perform better (because it means avoiding triggering code for more than one single backend when activated). It will also better support the flow if we eventually end up with a single backend again which then becomes the default. In that case, we don't need to maintain empty/obsolete minor-modes just to avoid breaking people's major-mode hooks. Then they will just have a defcustom setting which will be ignored. Personally I think that would work much better, and support the transitional period we may be entering, without causing lasting "cruft" in the code-base we rather would not have. Just my 2 cents. -- Jostein --------------PCeQltbIFMI4jvSGrSPg01cO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Yuan Fu <casouri@gmail.com> writes:


From the suggestions I collected from the old thread, here is my proposal:

We define a custom option treesit-settings (we can discuss the name
later), which controls whether to enable/disable tree-sitter for each
major mode, and the default preference, like this:

(defcustom treesit-settings '((t nil nil))
  "Tree-sitter toggles for major modes.

Hm...  well, there's also modes that are "pure treesit", and there are
(or will be) alternate modes with and without tree-sitter.

I think users basically fall into two camps: The ones that want to have
tree-sitter in all modes, and ones that want to enable it in specific
modes (and ones that don't want it at all).  (Note Computer
Science-mandated off-by-one error.)

This suggests to me that we should just use the normal minor mode
machinery that we have for these things.

That is, people that want treesit in python-mode will say:

(add-hook 'python-mode 'treesit-mode)

And people that want it everywhere will say:

(global-treesit-mode)

This mode will, in addition to switching `treesit-mode' on everywhere,
also set up `major-mode-remap-alist', so that `typescript-mode' is
mapped to `ts-mode', and `c-mode' is mapped to `treesit-c-mode' (which
I'm sure somebody is going to write in a couple of days), etc.

Hey there.

I'd like to come up with a somewhat contrarian point of view, if nothing else to provide a point of reference.

Right now we have a single (that is: one, 1) implementation for c-mode and c++-mode. They are based on cc-mode.

There's no c-mode where you enable usage of cc-mode through a minor-mode, nor is there a global-cc-mode toggle. And there's a really simple reason for that. That's because c-mode is implemented using cc-mode as a foundation, and there's no other implementations.

Now if we are starting to implement some new major-modes using treesitter as a foundation (for instance ts-mode or c#-mode), such a toggle for tree-sitter-mode will be equally pointless. There is no ts-mode without treesitter. And what should we do if people activate ts-mode without these bespoke minor-modes being active at the same time? I think it's a bit fuzzy and doesn't really sound very .. well defined.

Existing users of typescript-mode can be guided to the new implementation through a variety of ways, but to me the flow of activating typescript-mode major-mode, then treesit-minor-mode, and then magically switching to ts-mode makes absolutely no sense. And the performance of that is probably terrible too.

For those users I think a simple deprecation warning which informs about the new built-in ts-mode should be more than sufficient, for the users to clean out the old (buggy) typescript.el from their conigs.

The one place where it gets slightly complicated is for major-modes where one decides to have two or more canonical implementations, that is to add a new treesitter backend alongside the existing elisp-one.

For an established built in-mode, like c-mode, switching over night is probable not feasable nor desirable. So in practice you will have a few modes where you might have multiple backends, ideally only in a transitional phase, but in worst case scenario permanently.

So how can we deal with that problem, where we have it, and not everywhere else?

I've had a similar "problem" for LSP backend for some programming languages. The solution I landed on there was to have a defcustom per language/major-mode where there were different LSP-backends which I may want to use.

Examples below:

- (defcustom csharp-lsp-backend) ;; 'lsp-mode 'omnisharp

- (defcustom typescript-lsp-backend) ;; 'lsp-mode 'tide

Then I in my major-mode hooks checked for which of the possible backends are chosen and dynamically dispatch based on that.

For major-modes ending up with multiple backends, I think this is an approach which scales better (supports more than 1 backend, but only 1 at a time!), and will perform better (because it means avoiding triggering code for more than one single backend when activated).

It will also better support the flow if we eventually end up with a single backend again which then becomes the default. In that case, we don't need to maintain empty/obsolete minor-modes just to avoid breaking people's major-mode hooks. Then they will just have a defcustom setting which will be ignored.

Personally I think that would work much better, and support the transitional period we may be entering, without causing lasting "cruft" in the code-base we rather would not have.

Just my 2 cents.

--
Jostein



--------------PCeQltbIFMI4jvSGrSPg01cO--