unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	Eli Zaretskii <eliz@gnu.org>,
	emacs-devel@gnu.org
Subject: Re: Subversion of user chosen major mode by Emacs.
Date: Wed, 29 May 2024 19:22:13 +0000	[thread overview]
Message-ID: <ZleAZahm_9AV-3K_@ACM> (raw)
In-Reply-To: <4197c4a8-ee12-4fa7-9201-4d26f3be59c6@gutov.dev>

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).



  parent reply	other threads:[~2024-05-29 19:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28 10:53 My usage of imenu is broken Alan Mackenzie
2024-05-28 11:34 ` Eli Zaretskii
2024-05-28 13:57   ` Alan Mackenzie
2024-05-28 18:29     ` Eli Zaretskii
2024-05-28 20:46       ` Alan Mackenzie
2024-05-28 21:28         ` Stefan Monnier
2024-05-29  6:04           ` Juri Linkov
2024-05-29 11:31         ` Eli Zaretskii
2024-05-29  5:38       ` Yuan Fu
2024-05-28 21:55     ` Stefan Monnier
2024-05-29 11:16       ` Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] Alan Mackenzie
2024-05-29 11:43         ` Dmitry Gutov
2024-05-29 12:51           ` Subversion of user chosen major mode by Emacs Alan Mackenzie
2024-05-29 16:08             ` Dmitry Gutov
2024-05-29 16:38               ` Eli Zaretskii
2024-05-29 17:56                 ` Dmitry Gutov
2024-05-29 19:22               ` Alan Mackenzie [this message]
2024-05-29 19:45                 ` Andrea Corallo
2024-05-29 19:59                   ` Alan Mackenzie
2024-05-30  5:01                     ` Eli Zaretskii
2024-05-30 11:02                       ` Alan Mackenzie
2024-05-29 22:10                 ` Dmitry Gutov
2024-05-30  5:51                   ` Eli Zaretskii
2024-05-30  5:44                 ` Eli Zaretskii
2024-05-29 12:41         ` Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] Eli Zaretskii
2024-05-29 13:29           ` Subversion of user chosen major mode by Emacs Alan Mackenzie
2024-05-29 14:20             ` Eli Zaretskii
2024-05-29 15:04               ` Stefan Monnier
2024-05-29 19:17         ` Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] Eli Zaretskii
2024-05-30  1:32         ` Stefan Monnier
2024-05-30  5:25           ` Eli Zaretskii
2024-05-30  7:39             ` Po Lu
2024-05-30  7:53               ` Eli Zaretskii
2024-05-30 14:18             ` Stefan Monnier
2024-05-30 14:33               ` Po Lu
2024-05-30 15:08                 ` Stefan Monnier
2024-05-30 14:56               ` Eli Zaretskii
2024-05-30 15:12                 ` Stefan Monnier
2024-05-30 15:29                   ` Alan Mackenzie
2024-05-30 18:30                     ` Stefan Monnier
2024-05-30 16:06                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZleAZahm_9AV-3K_@ACM \
    --to=acm@muc.de \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).