From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Subversion of user chosen major mode by Emacs. Date: Wed, 29 May 2024 19:22:13 +0000 Message-ID: References: <86r0dmtbk2.fsf@gnu.org> <63afa31a-7874-4d1f-a17a-14a64ba516cb@gutov.dev> <4197c4a8-ee12-4fa7-9201-4d26f3be59c6@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37790"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 29 21:23:01 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 1sCOt2-0009hJ-U7 for ged-emacs-devel@m.gmane-mx.org; Wed, 29 May 2024 21:23:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCOsQ-000322-34; Wed, 29 May 2024 15:22:22 -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 1sCOsO-0002zs-MQ for emacs-devel@gnu.org; Wed, 29 May 2024 15:22:20 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCOsM-0001vt-Bc for emacs-devel@gnu.org; Wed, 29 May 2024 15:22:20 -0400 Original-Received: (qmail 86000 invoked by uid 3782); 29 May 2024 21:22:14 +0200 Original-Received: from muc.de (p4fe15a59.dip0.t-ipconnect.de [79.225.90.89]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 29 May 2024 21:22:14 +0200 Original-Received: (qmail 19113 invoked by uid 1000); 29 May 2024 19:22:13 -0000 Content-Disposition: inline In-Reply-To: <4197c4a8-ee12-4fa7-9201-4d26f3be59c6@gutov.dev> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319705 Archived-At: Hello, Dmitry. On Wed, May 29, 2024 at 19:08:46 +0300, Dmitry Gutov wrote: > Hi Alan, > On 29/05/2024 15:51, Alan Mackenzie wrote: > > On Wed, May 29, 2024 at 14:43:29 +0300, Dmitry Gutov wrote: > >> On 29/05/2024 14:16, Alan Mackenzie wrote: > >>>> I think this is a misfeature of `c-ts-mode.el`, but this was the result > >>>> of a long discussion and I don't think we want to revisit that yet. > >>> Why did nobody involve me in this discussion, considering that the > >>> result involves "stealing" CC Mode users? > >> This behavior is not new: loading a *-ts-mode has been overriding the > >> user preferences since 2023-01-20 (commit 6b2f85caa6). > > That has nothing to do with my point it is supposedly answering. > > 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. Perhaps if this had been done, the unpleasantness caused by major-mode-remap-alist/defaults could have been avoided. > > The problem comes in a comment in that patch encouraging users to > > subvert the proper meaning of c-mode, etc., from being specific modes to > > being vague generic modes. This is completely unnecessary for the > > normal user who uses only the *-ts- modes and not CC Mode. It is a > > confusing mess for users who wish to use both of these, say for > > comparison. > >> Perhaps your personal customization for auto-mode-alist had been > >> shielding you from the original issue. You can add a similar entry to > >> major-mode-remap-alist. > > Not sure what "original issue" you're referring to. My customisation > > for auto-mode-alist is an eval-after-load for c-ts-mode which deletes > > the *-ts- entries from auto-mode-alist. This has worked fine until > > recently and should be restored to working again. > Naturally, this only works while auto-mode-alist remains the last source > of truth regarding the mapping. As it should. major-mode-remap-alist and the other one add complexity to Emacs, confuse users (as they have confused me) and add no worthwhile facility to Emacs. > > All this confusion in auto-mode-alist, and the horrible workarounds of > > major-mode-remp_\(alist\|defaults\) result from a fundamental conceptual > > error, namely changing c-mode and friends from having specific meanings > > to being vague generic symbols. THIS is what I should have been > > consulted about, as the owner of these symbols. > I agree that the terminology might be confusing. We've had a discussion > regarding adding the notion of "languages" to Emacs (I even posted a > proposal), but so far we decided to go with the "lighter" solution. 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 latest symptom of this misunderstanding, which I bumped into > > yesterday, is that Emacs changes the major mode of a C buffer with M-x > > revert-buffer. This is clearly unacceptable. > 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. That is the purpose of major-mode-remap-defaults. There are other, better ways to set up c-ts-mode as the default default mode for C files. -- Alan Mackenzie (Nuremberg, Germany).