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: Turning on/off tree-sitter modes Date: Sat, 23 Nov 2024 18:36:37 +0200 Message-ID: <86a5dplxey.fsf@gnu.org> References: <6ac73c67-cb2d-48ef-8f1d-683c5335aba5@gutov.dev> <8634k4s2r2.fsf@gnu.org> <082b0388-b3a1-4523-9f9b-5ead4b110e11@gutov.dev> <86plmrtemx.fsf@gnu.org> <7aa4a684-3374-4d0f-8efc-c4df29337c5e@gutov.dev> <86cyirtahu.fsf@gnu.org> <556779b3-9308-4fd3-9050-bf9c49658cd1@gutov.dev> <864j43t8t9.fsf@gnu.org> <4cc676e8-cac5-4348-99b0-243baf74687e@gutov.dev> <8634jnt5e3.fsf@gnu.org> <4864104c-cb23-4356-ad89-2fea111db66c@gutov.dev> <86ttc2rrh8.fsf@gnu.org> <86cyipsp94.fsf@gnu.org> <9cd17f8b-f88c-49f6-9024-0b6d297e18ac@gutov.dev> <867c8xsmri.fsf@gnu.org> <566ac897-ea5e-4141-bcb3-306d43c9118a@gutov.dev> <865xohrvfa.fsf@gnu.org> <86wmgwnyle.fsf@gnu.org> <178dfc7f-bc2d-4e3b-8417-a616ccc0eef3@gutov.dev> <86v7wgnxlz.fsf@gnu.org> <01d83ec8-c02b-4806-8764-38dc89a89125@gutov.dev> <86ttbzojho.fsf@gnu.org> <930f5c8e-1481-43a5-8f1d-2c13a98df74f@gutov.dev> <86r072krq5.fsf@gnu.org> <8b907a41-aa08-4b61-bced-7d4d3fcef4b2@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38343"; mail-complaints-to="usenet@ciao.gmane.io" Cc: johan.myreen@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 23 17:37:31 2024 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 1tEt8U-0009qP-FU for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Nov 2024 17:37:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEt7h-0003JB-Af; Sat, 23 Nov 2024 11:36:41 -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 1tEt7f-0003Iu-NT for emacs-devel@gnu.org; Sat, 23 Nov 2024 11:36:39 -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 1tEt7f-0007Y0-5L; Sat, 23 Nov 2024 11:36:39 -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=q7w2NaLkJ601Dn/SaheqaO+mufLNdEtgpcx9nD9NUZs=; b=BOh87SxfBRq7 6I9cgij9DdLjK7cwf+ku5KHAu66CX6jrJuA5ACRf0Dh2IED8n9R/d+tjJcryZQrAsmp/BlmA4mvox 3xSZ7gctKn0xucxwYwyP+F0jZbwLrSMv6x2E6mmBX3k7rpsmtxNVXU9V5Ugu+h+s8WvkgN7fFhF1y bvJB8rMSp7N1WnLuZIWv61SC0SGwr+S98VKPKKqUcwwPlvWJHlTBbA5Hm8HSf+MQhkMKuAaACLUeQ qnUARQtUiTD3Z0yF4ZPct/dnDOR6oyY4pKOqHW04FtxtDv7Y3oO/YTrwqXJ/02Rdctzjl83hAn5am LgQLautH821xiwev0faUYA==; In-Reply-To: <8b907a41-aa08-4b61-bced-7d4d3fcef4b2@gutov.dev> (message from Dmitry Gutov on Sat, 23 Nov 2024 18:26:21 +0200) 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:325628 Archived-At: > Date: Sat, 23 Nov 2024 18:26:21 +0200 > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > > . we need the ability to turn on and off selected TS-based modes, > > and do it easily > > Note that we don't have such capability currently. We have, sort-of: loading the mode "turns it on" (with known caveats and disadvantages). In any case, I think we should have this, even if we don't have it now. It should be part of this improvement. > Both commands would be pure wrappers on top of the user option, so they > don't seem to require any advance considerations. Somebody can add those > later, or any variations on them. We could indeed make them wrappers, but changing the user option is not really clean. If nothing else, users will see that the option was "modified outside Custom", which could be confusing. But if we conclude that this is the best way, we could avoid this unpleasant effect as well (AFAIR, it is based on some special property of the option's symbol). > > . we should decide how to handle TS-based modes whose non-TS > > counterparts are available as 3rd-party packages > > I think we shouldn't do anything about those - they will continue to use > the current policy for 3rd party major modes: installing a package adds > an 'add-to-list' form to autoloads, which runs during > package-initialize. To disable such a form, the user uninstalls a package. Maybe. I'd be interested to hear what others think. > > . we should decide whether we want to modify auto-mode-alist or use > > major-mode remapping for all the TS-based modes > > I see no reason to depart from the current approach - except I've > switched from major-mode-remap-defaults to major-mode-remap-alist (where > the former is used) because the latter corresponds to user preferences, > and it seems like that's the subject of our switcher. > > This could also be discussed, but seems more of an orthogonal issue. Not really orthogonal, since I think Stefan was against changing auto-mode-alist, because it doesn't handle mode cookies and file-local variables.