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: An anonymous IRC user's opinion Date: Mon, 04 Nov 2024 21:18:56 +0200 Message-ID: <86v7x2u7rz.fsf@gnu.org> References: <87plodsjsd.fsf@web.de> <865xq14dwp.fsf@gnu.org> <343c4d04-af53-4da2-9d1c-c616c74821e1@gutov.dev> <86plo8369c.fsf@gnu.org> <63edeeea-1f24-4d3b-abc8-b96b164942e4@gutov.dev> <8634l1zsej.fsf@gnu.org> <9a8b97f8-def3-43ce-b71b-1f09bb05afd4@gutov.dev> <86cyk4vcld.fsf@gnu.org> <86ttdgthg2.fsf@gnu.org> <86ed4kt2ws.fsf@gnu.org> <8e30fb5c-8e1b-4f73-98eb-50c5c396efb0@gutov.dev> <86ldyqsrax.fsf@gnu.org> <10864c02-4bfd-41c3-bb45-6fe1155f9676@gutov.dev> <867ca9shcw.fsf@gnu.org> <7cb15f5c-efd0-4516-8190-a53c0d958eb6@gutov.dev> <86ses8x1po.fsf@gnu.org> <865xp3w64u.fsf@gnu.org> <61171da3-7428-4572-bc13-783766a123b5@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13468"; mail-complaints-to="usenet@ciao.gmane.io" Cc: johan.myreen@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 04 20:20:30 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 1t82cl-0003Jm-Ra for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Nov 2024 20:20:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t82bu-0000Pt-NA; Mon, 04 Nov 2024 14:19:35 -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 1t82bq-0000Pc-1r for emacs-devel@gnu.org; Mon, 04 Nov 2024 14:19:30 -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 1t82bp-00035B-6M; Mon, 04 Nov 2024 14:19:29 -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=EM+Mdb7MDuC4LLGSjGjPYK0fGaOQoTSKIeAq6IgNf1E=; b=ekyLOfF4Mvmo PKQ7/4Oa8BWP5hFExBX9RdVClv5M1vUhyWoGbumOZtqqJwSAdycPRBpdbFdpiO1TE1SyR4YTVz7EN Clx80LDDyn84CF7UYzWSoKbWt5V2NC6bWqawsEhgAuusZXLYV1CtKSd1Hm2fkQfP+nC7az6Yw7awZ Vj1i/LZfs1A/KuU90VHg++XS3tDcaRQ2RmKzGA+DO3NkDcDFgGZvTGdO/fFB/uH90dZRuPBza73Zt EQGpR5cnvb8QV1limsoHHNpXNbzJuRQP7qRpPpsWILpwc8F47iQmpH3eIfTtogBuWzPK14WyG5IxE 8rCyzk+h9NV5+XRuemB90Q==; In-Reply-To: <61171da3-7428-4572-bc13-783766a123b5@gutov.dev> (message from Dmitry Gutov on Mon, 4 Nov 2024 19:41:13 +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:325119 Archived-At: > Date: Mon, 4 Nov 2024 19:41:13 +0200 > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > On 04/11/2024 14:11, Eli Zaretskii wrote: > > > I'd prefer not to assume that the mere presence of libtree-sitter > > means the user wants to use modes. > > If we don't override existing traditional modes, what's the harm? Oh, but we do. Even if there's no mode defined for a file, people might expect to have Fundamental mode. We had this discussion before, and we even had someone who complained that some file suddenly turned on a TS mode where previously there was Fundamental mode. That was one of the reasons we made these modes optional in Emacs 29, so let's not repeat past mistakes. > If we > also exclude "small" modes like toml-ts-mode and dockerfile-ts-mode from > being enabled by default, we can be reasonably sure that when the user > visits a matching file, they will want to have the grammar installed. I don't think we can be reasonably sure, no. > > Without the user's say-so, this could be considered a nuisance. Why > > should Emacs annoy a user with some potential feature when the user > > didn't say she wants to use it? > > Could be considered a nuisance, or a boon. See above: we've been there already, and we know it isn't a boon. > Somebody tries to open a Go file, and sees *no* syntax highlighting, > indentation support, etc. When the grammar is not installed, our options > here are either: > > - Silently provide no features, nor explanations why they are not > working. Whether the major mode is enabled or not, it offers no > explanation on how to fix things. > > - Or issue a warning that the grammar is not installed. This would make > it easier to find the next steps. Silently providing no features (and relying on people to read the docs and set up their Emacs) is perhaps not the ideal situation, but annoying users with warning messages they didn't ask for is worse. Again, we've been there, and I'm not going to agree to go back. > Note that I don't have a goal of forcing tree-sitter on everybody: > previously I suggested to have all ts mode off by default. But if we're > going to set them up, the above seems to make the most sense. Not to me, it doesn't. Why is it a problem to ask users to whitelist some of these modes? > > At the very least we should > > perhaps have a special user option to tell that. In the simplest case > > it should be a simple boolean, but it could also be a list of > > languages/grammars for which to enable these modes. Then the relevant > > parts of auto-mode-alist should test that variable, in addition to > > whether tree-sitter is supported and available in general. > > This is also a valid approach, albeit a more complex one. This variable > would only be tested during Emacs' startup, though, and during > 'package-initialize', making its use not very transparent. It will be tested right there in auto-mode-alist, like the change you proposed, just with another test. > E.g. we > wouldn't react to having it changed in Customize. So it's not my > preferred approach to this problem. I don't see why this couldn't be a defcustom. > If we did have such a variable, though, we could enable more modes by > default. Subject to users whitelisting those modes? yes, that's the idea. > And it seems like it would be most consistent to enable all > tree-sitter modes that we have - including c-ts-mode and so on. I expect > some resistance to such a change. Again, if the user sets this variable to t, meaning enable all of TS modes, why would there be a resistance?