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: Tue, 05 Nov 2024 14:11:55 +0200 Message-ID: <86msidubg4.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> <86v7x2u7rz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11950"; 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 Tue Nov 05 13:12:52 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 1t8IQW-0002vZ-At for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Nov 2024 13:12:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8IPj-0005IF-Dd; Tue, 05 Nov 2024 07:12:03 -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 1t8IPg-0005Hy-SQ for emacs-devel@gnu.org; Tue, 05 Nov 2024 07:12:01 -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 1t8IPg-0004QK-7Z; Tue, 05 Nov 2024 07:12:00 -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=AwD+rJtNJuDsUycMjqySihFRbT+4F3b3ajKmkSRVK3k=; b=Giw82UtHsxuC ZWWyYEJZGKurTXRYch+wwxGkw2kTXtL0lbSOUIuLplaG4Jhv6wZHZhFsckiMY/gC9lUa0u+Hd2Q7Z xLd233w787osJFX9eRPamJ0qYIofxodzoALiLaw52URHjfVTqlFeyiPiJy0yW9SxdptMJMUAUQ9Ql rrrD3aORZQoTAzDx1ccYb9s65wlpB+WWsjIwEMJemGPRJgBB9hQeEBWiD4REgQFSyKxSrdEsTuInu Jqh8cQQY4EMApPKXBY1vf4dLDpI6DJ09B/oWDLjrOlg465HDwguvVeUp4Mo2nolu7r3HauhKlW/e0 jyETjy3gbSvfVpwb0wqS3g==; In-Reply-To: (message from Dmitry Gutov on Mon, 4 Nov 2024 22:59:06 +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:325134 Archived-At: > Date: Mon, 4 Nov 2024 22:59:06 +0200 > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > On 04/11/2024 21:18, Eli Zaretskii wrote: > > >> 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. > > That was with toml-ts-mode. > > So you think we should prioritize the scenario where people prefer > fundamental-mode over go-ts-mode or typescript-ts-mode as well? No, we should de-prioritize the scenario where what used to work without any warnings suddenly triggers warnings when visiting files, asking the user to install something she never asked for in the first place. (Are we really going to reiterate that old discussion? Nothing's changed since then, so the opinions and conclusions will be exactly the same.) > > See above: we've been there already, and we know it isn't a boon. > > We've been there in a particular configuration (one that included Emacs > being configured --without-tree-sitter). Since the person who uses Emacs is many times different from the one who configured it, I don't think that how Emacs was configured is relevant. > > Why is it a problem to ask users to whitelist some of these modes? > > Not a problem, no. They can do this already by customizing > major-mode-remap-alist, for example. That's true, but customizing a single variable might be easier and more easily discoverable, I'd think? If not, then we should leave things as they are. > >> 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. > > I'm concerned about the ergonomics of this option. What ergonomics? > >> 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. > > Would it have a non-default setter? Probably. Why is that a problem?