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: Subversion of user chosen major mode by Emacs. Date: Thu, 30 May 2024 08:44:56 +0300 Message-ID: <864jafsvjb.fsf@gnu.org> References: <86r0dmtbk2.fsf@gnu.org> <63afa31a-7874-4d1f-a17a-14a64ba516cb@gutov.dev> <4197c4a8-ee12-4fa7-9201-4d26f3be59c6@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6868"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 30 07:45:55 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 1sCYbq-0001bB-Ml for ged-emacs-devel@m.gmane-mx.org; Thu, 30 May 2024 07:45:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCYay-000619-UU; Thu, 30 May 2024 01:45:00 -0400 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 1sCYaw-0005tJ-QR for emacs-devel@gnu.org; Thu, 30 May 2024 01:44:59 -0400 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 1sCYav-0006dU-Rr; Thu, 30 May 2024 01:44:57 -0400 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=3Aa9duUBPiWsHcjadkc10OkUgiT/Lw/eOVue78m4/K4=; b=dE8FH6L2rvFh hvS0sCQgev9TuKpvSPFfjAKY6wQ30CfrMdMlCAiqkSSU8SD/ZzNBpjV/iwPBNJ/D957jsenEv6rqu MWnSWX06sSlz6oYknft6uV6UiVEx2OuPl5YhjwA6nnrAi/iyBAcj94l/id/m/aKynyca4o/QNikGQ YeUEl8UGNAvO9HDdNluM6yqYfuZluLVMLtrpHLzB0jKGQUmDi0w6zRyTfUs+glC5w42lt9rFUIp2x uDamsJc30HHSy90bKg++PHT0SsBtFW0XqRmEq5p2gIE5HKtWd6D8zEoRVWOTNFMmRK42LciMuaHHJ dHJQzFaN5WhIh0C3CffwTQ==; In-Reply-To: (message from Alan Mackenzie on Wed, 29 May 2024 19:22:13 +0000) 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:319722 Archived-At: > Date: Wed, 29 May 2024 19:22:13 +0000 > Cc: Stefan Monnier , Eli Zaretskii , > emacs-devel@gnu.org > From: Alan Mackenzie > > > > I've just had a look at that commit, and it simply adds entries to > > > auto-mode-alist for the *-ts-mode modes in the traditional, normal and > > > acceptable fashion. CC Mode does the same. > > > That's not the same thing: all CC Mode entries are behind ###autoload, > > meaning that the alist does not actually change when you load the file > > (as long as the autoloads are properly generated when you build Emacs). > > Ah yes, you're right. The entries to auto-mode-alist in cc-mode.el are > in comments (autoload comments), so that's one reason loading CC Mode > doesn't put those entries to the top of the alist. > > To be honest, I'm surprised that c-ts-mode and friends haven't come to > have autoload entries for auto-mode-alist, superseding those in CC Mode. The reason should be clear if you consider the intent: the TS modes are _optional_. We want to let users try them easily and make up their minds whether they like them better than the "traditional" modes for the same languages/content types, before they configure Emacs to use one or the other. It is impossible to do what CC Mode does for optional modes. Or at least it was tricky enough to implement as close to the release of Emacs 29 as we were when these decisions were made. More generally, Emacs has never seriously faced the situation that there's more than one major-mode for a particular programming language. The few cases that we did have (perl-mode vs cperl-mode, tex-mode vs AUCTeX, and some others) were each "resolved" by some lucky factor, like if one of the two modes fell into oblivion or one of them was not in core or whatever. This is the first time we had to deal with this problem, so some rough edges and semi-kludgey solutions should be expected. Dismissing the problems as if the solutions are simple and "at hand" doesn't help, because the easy solutions were already tried, and they all more-or-less failed. > Perhaps if this had been done, the unpleasantness caused by > major-mode-remap-alist/defaults could have been avoided. We tried something like that. It didn't work: people complained loudly (and rightfully so). You just don't remember it, or didn't pay attention, but it all played out here, and commit 6b2f85caa6 was the response to those problems. > Again, the source of the current problem was the misuse of the symbols > c-mode and c++-mode to mean something other than the major modes in CC > Mode. Again, nobody consulted me about this at all. The issue is not about CC Mode, it's about every mode that now has a sibling *-ts-mode that supports the same language/content type. Therefore, there was no need to consult you personally, when the discussions were all very public (and noisy). If you were interested, why haven't you chimed in back then? And given your publicly expressed lack of interest in c-ts-mode, can you really blame me for not reaching out to you personally? > > And that started happening since commit 6b2f85caa6, you can look for the > > related discussions and the objections that were voiced at the time. > > To be clear, what I find unacceptable is Emacs maintainers presuming to > override options explicitly set by the user with settings the maintainers > think are better. Emacs maintainers respect user options a lot. But your assertion above is simply false, because no user option was overridden, neither by commit 6b2f85caa6 nor by changes installed by Stefan in March. They both deal with variables that are not user options, and Emacs has been modifying the defaults used by user options since time immemorial. So your complaints in this matter are at least surprising.