My usage of imenu is broken.

My usage of imenu is broken.

[Alan Mackenzie]

Hello, Emacs.

imenu no longer works for me.  The imenu page in the Emacs manual says

    the command [imenu] always displays the whole list of valid names.  

This is not true.  When I type C-c i (my binding for imenu) I see no
such list.  When I additionally type TAB I still see no such list.  All
I see is *Rescan*, Function, and Variable.  I think the manual should be
fixed.

The manual talks about "flatten"ing without explaining what this means.
The NEWS item doesn't explain it either.  I think this should be fixed.

On typing C-c i, I used to be able to type the first characters of a
function name and complete it with TAB in the minibuffer.  This no
longer works.  It doesn't work even if I set imenu-flatten to t.
Instead I've got to type boilerplate first.  This is unacceptable to me.

How do I get the old behaviour back, please?  Why doesn't the NEWS item
say how to get back the old behaviour?

What happened to Emacs's convention that new facilities are disabled by
default to begin with, and only made the default after positive
experience with their use?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: My usage of imenu is broken.

[Eli Zaretskii]

> Date: Tue, 28 May 2024 10:53:18 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Emacs.
> 
> imenu no longer works for me.  The imenu page in the Emacs manual says
> 
>     the command [imenu] always displays the whole list of valid names.  
> 
> This is not true.  When I type C-c i (my binding for imenu) I see no
> such list.

AFAIK, this never worked literally as the manual says.  I went as far
back as Emacs 23, and I don't see it.

> When I additionally type TAB I still see no such list.

I do see the list after TAB.  So I guess the devil is in the details
(which file you were visiting, under what major mode, etc.) -- details
you haven't provided...

> All I see is *Rescan*, Function, and Variable.  I think the manual
> should be fixed.

Let's first understand why it doesn't work for you as it does for me.

> The manual talks about "flatten"ing without explaining what this means.
> The NEWS item doesn't explain it either.  I think this should be fixed.

Sadly, it is quite pointless to complain about deficiencies of
documentation in most cases, because no one which is in the position
to fix that is listening or can be bothered!

My advice is to invest the time, study the code (which will most
probably allow you to find ways of getting the behavior you want or
find and fix the bugs which prevent that), and fix the documentation
as required.  This way, everyone wins, starting from you!

And I did just that in this case: loaded 'imenu' and tried your
recipes.  Lo and behold, it does work for me, at least when I visit
src/dispnew.c from our tree (the first file I thought about, nothing
special about it).

> On typing C-c i, I used to be able to type the first characters of a
> function name and complete it with TAB in the minibuffer.  This no
> longer works.

It does for me.

> It doesn't work even if I set imenu-flatten to t.  Instead I've got
> to type boilerplate first.  This is unacceptable to me.
> 
> How do I get the old behaviour back, please?  Why doesn't the NEWS item
> say how to get back the old behaviour?

Old behavior in what Emacs version, please?  (In fact, you don't even
say in which version the above misbehavior happened to you, which I
find unexpected from you.)

> What happened to Emacs's convention that new facilities are disabled by
> default to begin with, and only made the default after positive
> experience with their use?

Nothing happened (except bugs, here and there).

Re: My usage of imenu is broken.

[Alan Mackenzie]

Hello, Eli.

On Tue, May 28, 2024 at 14:34:21 +0300, Eli Zaretskii wrote:
> > Date: Tue, 28 May 2024 10:53:18 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Emacs.

> > imenu no longer works for me.  The imenu page in the Emacs manual says

> >     the command [imenu] always displays the whole list of valid names.  

> > This is not true.  When I type C-c i (my binding for imenu) I see no
> > such list.

> AFAIK, this never worked literally as the manual says.  I went as far
> back as Emacs 23, and I don't see it.

> > When I additionally type TAB I still see no such list.

> I do see the list after TAB.  So I guess the devil is in the details
> (which file you were visiting, under what major mode, etc.) -- details
> you haven't provided...

> > All I see is *Rescan*, Function, and Variable.  I think the manual
> > should be fixed.

> Let's first understand why it doesn't work for you as it does for me.

I now understand what's happening.  Stefan M committed a patch some while
ago, the effect of which is to force users who've set up their
auto-mode-alist for CC Mode to use c-ts-mode, etc., instead.  It is in a
subroutine of normal-mode where this subterfuge occurs.

Yesterday, I'd reverted src/eval.c (which normally gets loaded via
desktop), and Stefan's patch converted it to c-ts-mode without me being
aware of this.

So my problem was being in c-ts-mode, for which all these things I don't
like about imenu are apparently normal.  It's one more reason for me to
carry on using CC Mode.

I'd wrongly jumped to the conclusion that what I was seeing was due to
recent changes in imenu.el, so apologies to yourself and those who
amended imenu.el.

> > The manual talks about "flatten"ing without explaining what this means.
> > The NEWS item doesn't explain it either.  I think this should be fixed.

> Sadly, it is quite pointless to complain about deficiencies of
> documentation in most cases, because no one which is in the position
> to fix that is listening or can be bothered!

:-(  Yes.  Maybe I should fix it myself.  Substandard documentation was
one of the things which led to the fall of XEmacs.

[ .... ]

> > How do I get the old behaviour back, please?  Why doesn't the NEWS item
> > say how to get back the old behaviour?

> Old behavior in what Emacs version, please?  (In fact, you don't even
> say in which version the above misbehavior happened to you, which I
> find unexpected from you.)

Sorry, I was in master, but not in emacs -Q.

[ .... ]

The bug "fix" and its patch which caused all this trouble were:

Bug#69191 New var `major-mode-remap-defaults`, for packages.

commit 2b5d43081a30f816dd38a16c7b5bfbad712a779b
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Sun Mar 3 23:08:16 2024 -0500

    (major-mode-remap(-defaults)): New var and function (bug#69191)

I don't understand what major-mode-remap and major-mode-remap-defaults
are for.  They would appear to be duplicating and confusing the mechanism
of auto-mode-alist, and seem unnecessary.  It seems clear they are too
difficult to use.

I would favour reverting that patch, and thus restore the preference of
users for CC Mode.

Stefan, your comments, please.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: My usage of imenu is broken.

[Eli Zaretskii]

> Date: Tue, 28 May 2024 13:57:46 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> So my problem was being in c-ts-mode, for which all these things I don't
> like about imenu are apparently normal.  It's one more reason for me to
> carry on using CC Mode.

I just now tried "M-x imenu" in c-ts-mode, and I don't see such a
catastrophe.  True, if you leave imenu-flatten at its default nil
value, you need to choose top-level "kind" of identifiers before you
can type the name.  For C, these "kinds" are Function, Variable, and
Struct.  Once you do select one of them, Imenu prompts you again, and
then you can type the identifiers, with completion, or type TAB to see
all of the names.

This is not very different from what you are used to.

Yuan, why does c-ts-mode' Imenu support behave differently in this
regard from CC Mode?  What was the rationale for the different
behavior?

Re: My usage of imenu is broken.

[Alan Mackenzie]

Hello, Eli

On Tue, May 28, 2024 at 21:29:43 +0300, Eli Zaretskii wrote:
> > Date: Tue, 28 May 2024 13:57:46 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > So my problem was being in c-ts-mode, for which all these things I don't
> > like about imenu are apparently normal.  It's one more reason for me to
> > carry on using CC Mode.

> I just now tried "M-x imenu" in c-ts-mode, and I don't see such a
> catastrophe.  True, if you leave imenu-flatten at its default nil
> value, you need to choose top-level "kind" of identifiers before you
> can type the name.  For C, these "kinds" are Function, Variable, and
> Struct.  Once you do select one of them, Imenu prompts you again, and
> then you can type the identifiers, with completion, or type TAB to see
> all of the names.

> This is not very different from what you are used to.

It's different enough to me to matter.  It adds boilerplate entry to
data entry, and would likely more than double the time to get to the
target function.  I'm not saying here that it's bad, just that it would
be bad for me.

I don't think anything like the CC Mode imenu style is available in the
c-ts-mode etc. modes.

> Yuan, why does c-ts-mode' Imenu support behave differently in this
> regard from CC Mode?  What was the rationale for the different
> behavior?

I'm not Yuan, but it could be a desire to support variables and structs
as well as just functions.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: My usage of imenu is broken.

[Stefan Monnier]

> It's different enough to me to matter.  It adds boilerplate entry to
> data entry, and would likely more than double the time to get to the
> target function.  I'm not saying here that it's bad, just that it would
> be bad for me.
>
> I don't think anything like the CC Mode imenu style is available in the
> c-ts-mode etc. modes.

FWIW, I think the problem partly lies on the side of `imenu`.
The API should let major modes provide the info once and for all, and
then the user should be able to choose whether they prefer to see it as
a few steps down a decision tree (e.g. first choose the category then
the identifier) or something else (e.g. completion of strings of the
form "<IDENT> <CATEGORY>", or order-agnostic so you can write
either "<IDENT> <CATEGORY>" or "<CATEGORY> <IDENT>", or ...).


        Stefan

Re: My usage of imenu is broken.

[Juri Linkov]

> FWIW, I think the problem partly lies on the side of `imenu`.
> The API should let major modes provide the info once and for all, and
> then the user should be able to choose whether they prefer to see it as
> a few steps down a decision tree (e.g. first choose the category then
> the identifier) or something else (e.g. completion of strings of the
> form "<IDENT> <CATEGORY>", or order-agnostic so you can write
> either "<IDENT> <CATEGORY>" or "<CATEGORY> <IDENT>", or ...).

While using a deep hierarchy of subcategories, it's clear how to order them
for the prefix option of 'imenu-flatten':

  "<SUB-CATEGORY-TOP> <SUB-CATEGORY-BOTTOM> <IDENT>"

But the suffix option of 'imenu-flatten' is ambiguous,
with the choice of whether to prefer this order:

  "<IDENT> <SUB-CATEGORY-TOP> <SUB-CATEGORY-BOTTOM>"

or

  "<IDENT> <SUB-CATEGORY-BOTTOM> <SUB-CATEGORY-TOP>"

Probably there is no *-ts-mode with more nested levels than 2,
but e.g. doc-view-imenu-index for a PDF with the hierarchical
table of contents both suffix orders make sense.

Re: My usage of imenu is broken.

[Eli Zaretskii]

> Date: Tue, 28 May 2024 20:46:48 +0000
> Cc: Yuan Fu <casouri@gmail.com>, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I just now tried "M-x imenu" in c-ts-mode, and I don't see such a
> > catastrophe.  True, if you leave imenu-flatten at its default nil
> > value, you need to choose top-level "kind" of identifiers before you
> > can type the name.  For C, these "kinds" are Function, Variable, and
> > Struct.  Once you do select one of them, Imenu prompts you again, and
> > then you can type the identifiers, with completion, or type TAB to see
> > all of the names.
> 
> > This is not very different from what you are used to.
> 
> It's different enough to me to matter.  It adds boilerplate entry to
> data entry, and would likely more than double the time to get to the
> target function.  I'm not saying here that it's bad, just that it would
> be bad for me.

Well, your original message sounded as if everything was completely
broken and nothing worked.

> > Yuan, why does c-ts-mode' Imenu support behave differently in this
> > regard from CC Mode?  What was the rationale for the different
> > behavior?
> 
> I'm not Yuan, but it could be a desire to support variables and structs
> as well as just functions.

If that's the reason, it can be handled with appropriate completion
tricks, like making the "kind" be a suffix rather than prefix, or
using substring completion style.

Re: My usage of imenu is broken.

[Yuan Fu]

> On May 28, 2024, at 11:29 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Tue, 28 May 2024 13:57:46 +0000
>> Cc: emacs-devel@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> So my problem was being in c-ts-mode, for which all these things I don't
>> like about imenu are apparently normal.  It's one more reason for me to
>> carry on using CC Mode.
> 
> I just now tried "M-x imenu" in c-ts-mode, and I don't see such a
> catastrophe.  True, if you leave imenu-flatten at its default nil
> value, you need to choose top-level "kind" of identifiers before you
> can type the name.  For C, these "kinds" are Function, Variable, and
> Struct.  Once you do select one of them, Imenu prompts you again, and
> then you can type the identifiers, with completion, or type TAB to see
> all of the names.
> 
> This is not very different from what you are used to.
> 
> Yuan, why does c-ts-mode' Imenu support behave differently in this
> regard from CC Mode?  What was the rationale for the different
> behavior?

Oh, I thought hierarchical is the canonical way to do imenus. But as Stefan said, imenu should allow users to choose whether to show the menu flat or nested. In fact, several packages (consult.el, counsel.el) flattens imenu for years.

Yuan

Re: My usage of imenu is broken.

[Stefan Monnier]

> I now understand what's happening.  Stefan M committed a patch some
> while ago, the effect of which is to force users who've set up their
> auto-mode-alist for CC Mode to use c-ts-mode, etc., instead.

That's one way to see it.  🙂

> Yesterday, I'd reverted src/eval.c (which normally gets loaded via
> desktop), and Stefan's patch converted it to c-ts-mode without me being
> aware of this.

The way I see it, the problem is in `c-ts-mode.el` where merely loading
the file changes the default mode to use for C files to `c-ts-mode`
(tho only in the current session, thank god).
My patch(es) only change(s) the mechanism used for that.

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.

> I don't understand what major-mode-remap and major-mode-remap-defaults
> are for.

They are designed to allow specifying which C mode Emacs should use
(not only for C, obviously).

In the past, `auto-mode-alist` way used for that, but that did not
account for cases where the major mode is not specified via the file
name, but instead via `-*- mode -*-`, or via `interpreter-mode-alist`,
or via ...
Also it encouraged `c-ts-mode.el` (and friends) duplicating
the regexps used to specify "this is probably a C file", often doing it
slightly differently from the other major mode.

Instead, conceptually `auto-mode-alist` should now be used to specify
the type of content (tho represented not as something like a MIME type
but as a symbol that (usually) denotes a major mode), and then
`major-mode-remap` is used to decide which major mode to use for that
file type.

> They would appear to be duplicating and confusing the mechanism
> of auto-mode-alist, and seem unnecessary.  It seems clear they are too
> difficult to use.

Clear as mud, indeed.


        Stefan

Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Alan Mackenzie]

Hello, Stefan.

On Tue, May 28, 2024 at 17:55:28 -0400, Stefan Monnier wrote:
> > I now understand what's happening.  Stefan M committed a patch some
> > while ago, the effect of which is to force users who've set up their
> > auto-mode-alist for CC Mode to use c-ts-mode, etc., instead.

> That's one way to see it.  🙂



> > Yesterday, I'd reverted src/eval.c (which normally gets loaded via
> > desktop), and Stefan's patch converted it to c-ts-mode without me being
> > aware of this.

> The way I see it, the problem is in `c-ts-mode.el` where merely loading
> the file changes the default mode to use for C files to `c-ts-mode`
> (tho only in the current session, thank god).

What's wrong with that?  "Merely" loading CC Mode adds entries to
auto-mode-alist for this.  Surely lots of other libraries do this, too.

> My patch(es) only change(s) the mechanism used for that.

No.  It/they subvert(s) the mode chosen by the user.  As I said, when I
did M-x revert-buffer yesterday, Emacs changed my major mode from C Mode
to c-ts-mode.  This is clearly unacceptable.

It is unacceptable to subvert the major mode set up by the user to some
other mode.  This is exactly what major-mode-remap-defaults is designed
to do.  If a user wishes to make such a substition that is her good
right, but for the Emacs maintainers silently to impose such a
substition on users is something else entirely.

> 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?

> > I don't understand what major-mode-remap and major-mode-remap-defaults
> > are for.

> They are designed to allow specifying which C mode Emacs should use
> (not only for C, obviously).

That is what auto-mode-alist is for.  These two new alists do not add
useful functionality, they just add complexity, and they confuse users.

> In the past, `auto-mode-alist` way used for that, but that did not
> account for cases where the major mode is not specified via the file
> name, but instead via `-*- mode -*-`, or via `interpreter-mode-alist`,
> or via ...

That's a case of going for 100% perfection at the expense of the normal
case.  People don't put -*- c-mode -*- into files.  Not as a general
rule.

c-mode and c++-mode are registered trade marks of CC Mode, much as Emacs
means GNU Emacs, not any other editor with similar functionality.  If
somebody has specified -*- c-mode -*-, then they mean CC Mode.  If they
don't, they should write -*- c-ts-mode -*- instead, or Emacs should
provide something like -*- c-generic-mode -*-.

> Also it encouraged `c-ts-mode.el` (and friends) duplicating
> the regexps used to specify "this is probably a C file", often doing it
> slightly differently from the other major mode.

Surely a trivial problem, if a problem at all.

> Instead, conceptually `auto-mode-alist` should now be used to specify
> the type of content (tho represented not as something like a MIME type
> but as a symbol that (usually) denotes a major mode), and then
> `major-mode-remap` is used to decide which major mode to use for that
> file type.

Oh deity, no!  auto-mode-alist specifies the MODE, not some abstract
"content type".  You're proposing duplicating the entries in
auto-mode-alist with another list of the same size.  This can only cause
user confusion when instead of pushing an element to a-m-a, they also
have to push one to m-m-remap, and make sure they match up.

The solution to this problem is to emphasise that auto-mode-alist is an
alist of filenames and major modes, like it always has been.

> > They would appear to be duplicating and confusing the mechanism
> > of auto-mode-alist, and seem unnecessary.  It seems clear they are too
> > difficult to use.

> Clear as mud, indeed.

Then lets sort this out.  How about you proposing a solution to M-x
revert-buffer changing a buffer's major mode?  My solution would be to
revert the patch that introduced major-mode-remap-defaults.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Dmitry Gutov]

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

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.

Re: Subversion of user chosen major mode by Emacs.

[Alan Mackenzie]

Hello, Dmitry.

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.

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.

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.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs.

[Dmitry Gutov]

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

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

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

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

Re: Subversion of user chosen major mode by Emacs.

[Eli Zaretskii]

> Date: Wed, 29 May 2024 19:08:46 +0300
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > 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

No, it didn't.  That commit changed nothing about how revert-buffer
behaves.  Please stop these insinuations.  I said I don't want to go
into that argument again, so you want to force me??  Just let it be.

Re: Subversion of user chosen major mode by Emacs.

[Dmitry Gutov]

On 29/05/2024 19:38, Eli Zaretskii wrote:
>> Date: Wed, 29 May 2024 19:08:46 +0300
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> 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
> 
> No, it didn't.  That commit changed nothing about how revert-buffer
> behaves.

That's true, apologies for being imprecise: 'M-x revert-buffer' has 
always re-applied the configured major mode. The odds of it being 
changed (due to the change in configuration) just increased somewhat 
with the commit I mentioned.

> Please stop these insinuations.  I said I don't want to go
> into that argument again, so you want to force me??  Just let it be.

Sorry, I just wanted to get everyone on the same page.

Re: Subversion of user chosen major mode by Emacs.

[Alan Mackenzie]

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

Re: Subversion of user chosen major mode by Emacs.

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

[...]

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

Hi Alan,

please assume the good faith of the other developers here.
'major-mode-remap-defaults' was added for (valid or not) technical
reasons and it might very well come with (good or bad) consequences we
can discuss, but there's no conspiracy here.

Thanks

  Andrea

Re: Subversion of user chosen major mode by Emacs.

[Alan Mackenzie]

Hello, Andrea.

On Wed, May 29, 2024 at 15:45:37 -0400, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> [...]

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

> Hi Alan,

> please assume the good faith of the other developers here.
> 'major-mode-remap-defaults' was added for (valid or not) technical
> reasons and it might very well come with (good or bad) consequences we
> can discuss, but there's no conspiracy here.

Just to be clear, I don't doubt the good faith of others, here.  When I
wrote about "the purpose of major-mode-remap-defaults" I meant it
literally, ascribing motivation to the variable, not to maintainers.
Sorry I wasn't clearer.

My intention was to make other maintainers, including he who wrote it,
aware of what was at stake.  There's a very old principle in Emacs not
to interfere in user set options.  That's what I see being violated
here.

> Thanks

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs.

[Eli Zaretskii]

> Date: Wed, 29 May 2024 19:59:23 +0000
> Cc: Dmitry Gutov <dmitry@gutov.dev>,
>   Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> My intention was to make other maintainers, including he who wrote it,
> aware of what was at stake.

We are aware.

> There's a very old principle in Emacs not to interfere in user set
> options.

auto-mode-alist is NOT a user option, never was.  Emacs has been
tweaking its value for users' benefits for eons, and CC Mode does that
as well.

major-mode-remap-alist _is_ a user option, which is one reason why
solutions proposed back when Emacs 29 was in the works that involved
changing the value of major-mode-remap-alist were unacceptable to me.
The changes installed by Stefan don't touch major-mode-remap-alist,
probably for the same reason; instead, they introduce a new internal
variable and tweak that.

> That's what I see being violated here.

No, it is not.

Re: Subversion of user chosen major mode by Emacs.

[Alan Mackenzie]

Hello, Eli.

On Thu, May 30, 2024 at 08:01:36 +0300, Eli Zaretskii wrote:
> > Date: Wed, 29 May 2024 19:59:23 +0000
> > Cc: Dmitry Gutov <dmitry@gutov.dev>,
> >   Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > My intention was to make other maintainers, including he who wrote it,
> > aware of what was at stake.

> We are aware.

> > There's a very old principle in Emacs not to interfere in user set
> > options.

> auto-mode-alist is NOT a user option, never was.  Emacs has been
> tweaking its value for users' benefits for eons, and CC Mode does that
> as well.

> major-mode-remap-alist _is_ a user option, which is one reason why
> solutions proposed back when Emacs 29 was in the works that involved
> changing the value of major-mode-remap-alist were unacceptable to me.
> The changes installed by Stefan don't touch major-mode-remap-alist,
> probably for the same reason; instead, they introduce a new internal
> variable and tweak that.

> > That's what I see being violated here.

> No, it is not.

My decision to use C Mode rather than c-ts-mode I see as a user option
exercised by me.  Two days ago, that choice of mine was usurped, when
Emacs decided that rather than c-mode, I really wanted c-ts-mode.

The point here is we have identity theft.  The symbol c-mode is the name
of CC Mode's mode for C.  It has no other name.  The symbol belongs to
CC Mode.  But others have decided that c-mode is to have additional
meanings, diluting its primary meaning.  It is as though somebody
decided that "Eli Zaretskii", rather than meaning you, meant "a generic
Emacs maintainer".  You would not like it.

Anyhow, I see a way forward.  I will amend CC Mode also to make entries
in major-mode-remap-defaults.  This would appear to be in the spirit of
that undocumented variable.  It doesn't feel ideal, though.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs.

[Dmitry Gutov]

Hi Alan,

On 29/05/2024 22:22, Alan Mackenzie wrote:

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

IIUC, the current state of affairs is an attempt to balance the needs of 
users who want to test out and use the tree-sitter modes with as little 
friction as possible, against the needs of older users who can get 
annoyed at the switch in the defaults (and the extra work required to 
install the tree-sitter libraries, bug#60559).

Re: Subversion of user chosen major mode by Emacs.

[Eli Zaretskii]

> Date: Thu, 30 May 2024 01:10:04 +0300
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > 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.
> 
> IIUC, the current state of affairs is an attempt to balance the needs of 
> users who want to test out and use the tree-sitter modes with as little 
> friction as possible, against the needs of older users who can get 
> annoyed at the switch in the defaults

True.

Re: Subversion of user chosen major mode by Emacs.

[Eli Zaretskii]

> Date: Wed, 29 May 2024 19:22:13 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> Date: Wed, 29 May 2024 11:16:44 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> As I said, when I did M-x revert-buffer yesterday, Emacs changed my
> major mode from C Mode to c-ts-mode.  This is clearly unacceptable.

Please show a minimal recipe, starting from "emacs -Q", where
reverting a buffer changes from c-mode to c-ts-mode.

As a general rule, revert-buffer does not guarantee the major mode
will remain the same, not by default.  It calls normal-mode, so if
anything has changed in automatic determination of the mode, you will
get a different mode.  This is by design.

Re: Subversion of user chosen major mode by Emacs.

[Alan Mackenzie]

Hello, Eli.

On Wed, May 29, 2024 at 15:41:45 +0300, Eli Zaretskii wrote:
> > Date: Wed, 29 May 2024 11:16:44 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > As I said, when I did M-x revert-buffer yesterday, Emacs changed my
> > major mode from C Mode to c-ts-mode.  This is clearly unacceptable.

> Please show a minimal recipe, starting from "emacs -Q", where
> reverting a buffer changes from c-mode to c-ts-mode.

With a recent master emacs:
(i) emacs -Q
(ii) Insert the following into *scratch* and evaluate it:

(defun c-make-ts-undefault-mode ()
  "Make the older C and C++ Modes the default major modes for C(++)
files."
  (interactive)
  (let (c)
    (dolist (l '(c-ts-mode c++-ts-mode c-or-c++-ts-mode))
      (while (setq c (rassq l auto-mode-alist))
        (setq auto-mode-alist (remq c auto-mode-alist))))))
(eval-after-load 'c-ts-mode '(c-make-ts-undefault-mode))

(load-library "cc-mode")

..

(iii) C-x C-f src/xdisp.c.  This is loaded with C Mode.
(iv) M-: (load-library "c-ts-mode").
(v) M-x revert-buffer.  Emacs reloads the buffer in c-ts-mode.

> As a general rule, revert-buffer does not guarantee the major mode
> will remain the same, not by default.  It calls normal-mode, so if
> anything has changed in automatic determination of the mode, you will
> get a different mode.  This is by design.

Such changes to the automatic determination should be as a result of
user choices.  There shouldn't be nasty surprises in store.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs.

[Eli Zaretskii]

> Date: Wed, 29 May 2024 13:29:34 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Please show a minimal recipe, starting from "emacs -Q", where
> > reverting a buffer changes from c-mode to c-ts-mode.
> 
> With a recent master emacs:
> (i) emacs -Q
> (ii) Insert the following into *scratch* and evaluate it:
> 
> (defun c-make-ts-undefault-mode ()
>   "Make the older C and C++ Modes the default major modes for C(++)
> files."
>   (interactive)
>   (let (c)
>     (dolist (l '(c-ts-mode c++-ts-mode c-or-c++-ts-mode))
>       (while (setq c (rassq l auto-mode-alist))
>         (setq auto-mode-alist (remq c auto-mode-alist))))))
> (eval-after-load 'c-ts-mode '(c-make-ts-undefault-mode))
> 
> (load-library "cc-mode")
> 
> ..
> 
> (iii) C-x C-f src/xdisp.c.  This is loaded with C Mode.
> (iv) M-: (load-library "c-ts-mode").
> (v) M-x revert-buffer.  Emacs reloads the buffer in c-ts-mode.

I can't say I'm happy with Stefan's change in commit 2b5d43081a,
especially with the fact that it overruled my opinions about such a
change without even mentioning that, let alone asking me, but frankly
I'm tired of holding this fort alone, with everyone else and their dog
telling me I don't know what I'm talking about,
major-mode-remap-alist/defaults being the best invention since sliced
bread.  Let others fight this battle now, because all that is left to
me to do, if I'm unwilling to give in, is to step down.  Maybe I
will...

But anyway, why do you consider the above kludges wrt auto-mode-alist
more "kosher" and worthy of our support than the similar kludge you
could do with major-mode-remap-defaults for Emacs 30 and later?  They
are both kludges one isn't supposed to do.

> > As a general rule, revert-buffer does not guarantee the major mode
> > will remain the same, not by default.  It calls normal-mode, so if
> > anything has changed in automatic determination of the mode, you will
> > get a different mode.  This is by design.
> 
> Such changes to the automatic determination should be as a result of
> user choices.  There shouldn't be nasty surprises in store.

When you load c-ts-mode, you tell Emacs you want to visit C files in
c-ts-mode.  If you want to go back, restart Emacs.  That has not
changed with Stefan's commit.  Yes, there are kludges to undo the
effect of loading c-ts-mode, and they are still there, you just need
to adapt them.  How is that a grave problem?

Re: Subversion of user chosen major mode by Emacs.

[Stefan Monnier]

> But anyway, why do you consider the above kludges wrt auto-mode-alist
> more "kosher" and worthy of our support than the similar kludge you
> could do with major-mode-remap-defaults for Emacs 30 and later?
> They are both kludges one isn't supposed to do.

The "official" way to do it not is by customizing
`major-mode-remap-alist`, e.g.

    (push '(c-mode . c-mode) major-mode-remap-alist)

or do the same via Custom.
And you don't need to do that in a `with-eval-after-load`.


        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> Date: Wed, 29 May 2024 11:16:44 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > In the past, `auto-mode-alist` way used for that, but that did not
> > account for cases where the major mode is not specified via the file
> > name, but instead via `-*- mode -*-`, or via `interpreter-mode-alist`,
> > or via ...
> 
> That's a case of going for 100% perfection at the expense of the normal
> case.  People don't put -*- c-mode -*- into files.  Not as a general
> rule.
> 
> c-mode and c++-mode are registered trade marks of CC Mode, much as Emacs
> means GNU Emacs, not any other editor with similar functionality.  If
> somebody has specified -*- c-mode -*-, then they mean CC Mode.

Actually, this may or may not be true.  There are cases where people
put "-*- c++ -*-" etc. in files, but any mode supporting C++ will do.
As one example, consider the libstdc++ headers such as 'algorithm' and
others that have no file-name extension: it is clear that the mode
cookie there does not necessarily mean these files should only be
edited with c++-mode.  As another example, consider the *.h files that
are part of GDB sources: not every header file there will be
identified by Emacs as C++ just by looking at the contents, so the GDB
developers want to make sure Emacs turns on some C++ supporting mode
when editing these files.

As yet another example, consider our .dir-locals.el files: the
mode-specific settings there don't care whether the user uses c-mode
or c-ts-mode to edit our C sources.

And there can be other examples.  So sometimes the major mode symbol
does in fact stand for the type of content and not for the specific
mode it names.  And Emacs should support these use cases, because
users are rightfully annoyed when they need to duplicate the same
boring settings.

> or Emacs should provide something like -*- c-generic-mode -*-.

That'd be swell, and we do provide these in some cases.  But doing so
is only possible if the maintainers of the related modes agree to
cooperate to bring their modes closer.  And you at the time were not
very enthusiastic, to say the least, about any such involvement.  So
here we are.

> > Also it encouraged `c-ts-mode.el` (and friends) duplicating
> > the regexps used to specify "this is probably a C file", often doing it
> > slightly differently from the other major mode.
> 
> Surely a trivial problem, if a problem at all.

Actually, our experience since introduction of the *-ts-modes
indicates it is not a trivial problem at all.  To wit: we don't yet
have a good solution for it, and several naïve attempts proved to
cause problems we needed to fix.  It is surprising how a typical
mode's simplest definitions are tightly coupled with the
implementation of the basic features we need for major modes:
font-lock, indentation, syntax analysis, etc.  It turns out our
abstractions in that department leak like hell.

> > Instead, conceptually `auto-mode-alist` should now be used to specify
> > the type of content (tho represented not as something like a MIME type
> > but as a symbol that (usually) denotes a major mode), and then
> > `major-mode-remap` is used to decide which major mode to use for that
> > file type.
> 
> Oh deity, no!  auto-mode-alist specifies the MODE, not some abstract
> "content type".

See above: not necessarily true, at least not in all cases.

And note that mode symbols are used not only in auto-mode-alist.  A
very frequent use is as an argument to the likes of derived-mode-p.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Stefan Monnier]

> If somebody has specified -*- c-mode -*-, then they mean CC Mode.
> If they don't, they should write -*- c-ts-mode -*- instead, or Emacs
> should provide something like -*- c-generic-mode -*-.

I strongly disagree: file-local variables should describe the file's
content, not the user's favorite environment to edit it.
Otherwise, it's impossible for two users who have different preferences
to share that file.


        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 29 May 2024 21:32:05 -0400
> 
> > If somebody has specified -*- c-mode -*-, then they mean CC Mode.
> > If they don't, they should write -*- c-ts-mode -*- instead, or Emacs
> > should provide something like -*- c-generic-mode -*-.
> 
> I strongly disagree: file-local variables should describe the file's
> content, not the user's favorite environment to edit it.

How do we know that this was the intent?  It could be either of these
two, whether you like it or not.

If we want to know for sure, perhaps we need to introduce a new kind
of cookie, like 'force-mode: c++-mode' or somesuch.

> Otherwise, it's impossible for two users who have different preferences
> to share that file.

How do I force the use of a specific mode when more than one can
handle the file?  It is possible that the file relies on some features
specific to that mode, so such use cases are not outlandish.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> How do we know that this was the intent?  It could be either of these
> two, whether you like it or not.
>
> If we want to know for sure, perhaps we need to introduce a new kind
> of cookie, like 'force-mode: c++-mode' or somesuch.

eval: (c-mode 1)

?

Disclaimer, this hasn't been tested.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  acm@muc.de,
>   emacs-devel@gnu.org
> Date: Thu, 30 May 2024 15:39:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do we know that this was the intent?  It could be either of these
> > two, whether you like it or not.
> >
> > If we want to know for sure, perhaps we need to introduce a new kind
> > of cookie, like 'force-mode: c++-mode' or somesuch.
> 
> eval: (c-mode 1)
> 
> ?

Using 'eval' is problematic because it isn't considered safe in local
variables.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Stefan Monnier]

>> Otherwise, it's impossible for two users who have different preferences
>> to share that file.
> How do I force the use of a specific mode when more than one can
> handle the file?  It is possible that the file relies on some features
> specific to that mode, so such use cases are not outlandish.

AFAICT it is a lot more common for file-local vars to be abused to
specify mere user preferences, than the reverse (i.e. where there really
is a technical reason why the file should be edited with js2-mode rather
than js-mode).


        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Otherwise, it's impossible for two users who have different preferences
>>> to share that file.
>> How do I force the use of a specific mode when more than one can
>> handle the file?  It is possible that the file relies on some features
>> specific to that mode, so such use cases are not outlandish.
>
> AFAICT it is a lot more common for file-local vars to be abused to
> specify mere user preferences, than the reverse (i.e. where there really
> is a technical reason why the file should be edited with js2-mode rather
> than js-mode).

True, but this doesn't answer Eli's question.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Stefan Monnier]

>> AFAICT it is a lot more common for file-local vars to be abused to
>> specify mere user preferences, than the reverse (i.e. where there really
>> is a technical reason why the file should be edited with js2-mode rather
>> than js-mode).
> True, but this doesn't answer Eli's question.

No, I didn't feel the need to repeat your answer.

And of course there are various other solutions: this is Emacs we're
talking about, so you can "always" code-your way around any special case.

E.g. it's easy enough to

    (defalias 'cc-c-mode #'c-mode)

and then use

    -*- cc-c -*-

And if it ever turns into a common enough need, it'll be easy to
streamline one of those solutions.


        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Thu, 30 May 2024 10:18:49 -0400
> 
> >> Otherwise, it's impossible for two users who have different preferences
> >> to share that file.
> > How do I force the use of a specific mode when more than one can
> > handle the file?  It is possible that the file relies on some features
> > specific to that mode, so such use cases are not outlandish.
> 
> AFAICT it is a lot more common for file-local vars to be abused to
> specify mere user preferences, than the reverse (i.e. where there really
> is a technical reason why the file should be edited with js2-mode rather
> than js-mode).

"More common", maybe.  But that doesn't mean the other case doesn't
exist or is not legitimate.

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Stefan Monnier]

>> AFAICT it is a lot more common for file-local vars to be abused to
>> specify mere user preferences, than the reverse (i.e. where there really
>> is a technical reason why the file should be edited with js2-mode rather
>> than js-mode).
> "More common", maybe.  But that doesn't mean the other case doesn't
> exist or is not legitimate.

I don't doubt such cases exist.  I personally can't think of any, tho.
So, being hypothetical, I tend to consider it as a fringe problem which
is OK to solve with fringe solutions.

Can you point to non-hypothetical examples?


        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Alan Mackenzie]

Hello, Stefan.

On Thu, May 30, 2024 at 11:12:44 -0400, Stefan Monnier wrote:
> >> AFAICT it is a lot more common for file-local vars to be abused to
> >> specify mere user preferences, than the reverse (i.e. where there really
> >> is a technical reason why the file should be edited with js2-mode rather
> >> than js-mode).
> > "More common", maybe.  But that doesn't mean the other case doesn't
> > exist or is not legitimate.

> I don't doubt such cases exist.  I personally can't think of any, tho.
> So, being hypothetical, I tend to consider it as a fringe problem which
> is OK to solve with fringe solutions.

> Can you point to non-hypothetical examples?

I can point to a semi-hypothetical case: A device driver hacker may need
to use C Mode for a "hardware description" file which contains a 40,000
line function, for which c-ts-mode is unusably slow.  I have such a
file, packet-rrc.c, in my desktop.  The said hacker may, however, prefer
c-ts-mode for more normal files, so will set up the mode in file-local
variables or the top line of the file.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Stefan Monnier]

> I can point to a semi-hypothetical case: A device driver hacker may need
> to use C Mode for a "hardware description" file which contains a 40,000
> line function, for which c-ts-mode is unusably slow.  I have such a
> file, packet-rrc.c, in my desktop.  The said hacker may, however, prefer
> c-ts-mode for more normal files, so will set up the mode in file-local
> variables or the top line of the file.

I see.  To me that sounds like a fringe enough case that a fringe
solution is OK (while waiting for `c-ts-mode` to fix that problem).
[ And of course, forcing `c-mode` for that one file may annoy that other
  contributor who prefers `sm-c-mode` instead.  🙂  ]

        Stefan

Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Thu, 30 May 2024 11:12:44 -0400
> 
> Can you point to non-hypothetical examples?

Alan is a non-hypothetical person who claims that his uses of that are
real.