GNU bug report logs - #58075
Mapping file types to major modes

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58075 in the body.
You can then email your comments to 58075 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: Mapping file types to major modes
Date: Sun, 25 Sep 2022 11:38:28 -0400

[Message part 1 (text/plain, inline)]

Tags: patch

[ I now see that I had sent this to `emacs-devel` rather than as a bug
  report, so here is the second try.  To make up for it, I include
  a suggested patch this time.  ]

Emacs has various facilities to decide which major mode to use for which
file based on its name and/or contents.  All those facilities specify
directly the mode to use.  This is usually exactly what we want because
there's only ever 1 major mode for that type.

But for some file types this is inconvenient because there are various
alternative major modes that can be used for that file type.
I'm thinking of things like Perl files (`perl-mode` vs `cperl-mode`),
LaTeX files (`latex-mode` vs AUCTeX's equivalent (whose name it not
clear, sadly)), HTML files (lots of alternatives), ...

We have various ways to deal with those different cases, which are
variously convenient/successful, but for things like `cperl-mode` vs
`perl-mode` or `latex-mode` vs AUCTeX the usual solution is not
satisfactory since it looks like:

    (defalias 'perl-mode #'cperl-mode)

or equivalent, which means that the "other" mode becomes unavailable,
which is particularly problematic if we want the "fancy/external" mode to
be a derived mode of the other.
(AUCTeX now does it via advising which at least makes it reversible,
but it's still not very satisfactory).

The way I tend to think of it is that we'd like to divide the mode
choice into two steps:

A) recognize the file type (a bit like `/etc/mime.types`).
B) choose the mode to use for that type (like `/etc/mailcap`).

We don't current have "types" and retro-fitting that might make the common
case (where there's only 1 mode) more painful.  IOW it would take work
and lead to a worse result in the most common case, which doesn't sound
very enticing.

So instead I suggest consider the current settings as being our
implementation of (A), and add (B) as some "mode remapping" layer to
decide which major mode to actually for a given "type/mode".
So instead of

    (defalias 'perl-mode #'cperl-mode)

We could have

    (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))


-- Stefan


 In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2022-09-16 built on pastel
Repository revision: c15a53877a7db7aa3205cff3c943321ed81a1412
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

[major-mode-remap.patch (text/patch, attachment)]

Message #8 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58075 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Mon, 26 Sep 2022 13:26:48 +0200

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

> We have various ways to deal with those different cases, which are
> variously convenient/successful, but for things like `cperl-mode` vs
> `perl-mode` or `latex-mode` vs AUCTeX the usual solution is not
> satisfactory since it looks like:
>
>     (defalias 'perl-mode #'cperl-mode)

Isn't the usual solution to just make `auto-mode-alist' map .pl to
cperl-mode instead of perl-mode?

Hm, well, that's

     ("\\.\\([pP]\\([Llm]\\|erl\\|od\\)\\|al\\)\\'" . perl-mode)

so it's a bit of a mouthful.

> We could have
>
>     (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))

This area is already pretty complicated, so I worry that this is going
to make things even more confusing.  But perhaps it's worth it?

Message #11 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58075 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Mon, 26 Sep 2022 08:13:34 -0400

Lars Ingebrigtsen [2022-09-26 13:26:48] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> We have various ways to deal with those different cases, which are
>> variously convenient/successful, but for things like `cperl-mode` vs
>> `perl-mode` or `latex-mode` vs AUCTeX the usual solution is not
>> satisfactory since it looks like:
>>
>>     (defalias 'perl-mode #'cperl-mode)
>
> Isn't the usual solution to just make `auto-mode-alist' map .pl to
> cperl-mode instead of perl-mode?
>
> Hm, well, that's
>
>      ("\\.\\([pP]\\([Llm]\\|erl\\|od\\)\\|al\\)\\'" . perl-mode)
>
> so it's a bit of a mouthful.

And that doesn't account for the files where the mode is found by
`interpreter-mode-list`, by `mode:` cookies, etc...


        Stefan

Message #14 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58075 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Tue, 27 Sep 2022 14:54:59 +0200

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

> And that doesn't account for the files where the mode is found by
> `interpreter-mode-list`, by `mode:` cookies, etc...

Yup.  So I think your proposed patch makes a lot of sense, so feel free
to push.

Message #17 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 58075 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Wed, 28 Sep 2022 17:15:43 +0900

Hi Stefan,

>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> So instead I suggest consider the current settings as being our
> implementation of (A), and add (B) as some "mode remapping" layer to
> decide which major mode to actually for a given "type/mode".
> So instead of

>     (defalias 'perl-mode #'cperl-mode)

> We could have

>     (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))

In your proposed patch, `major-mode-remap-alist' is a user option
defined by `defcustom'.

Is it supposed to be legitimate that a site administrator sets up the
default mapping for the site as
>     (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))
in site-start.el?

Currently, a site admin can place AUCTeX activation code
     (load "auctex.el" nil t t)
in site-start.el to prepare AUCTeX to be the site-wide default TeX mode.
In auctex.el, (require 'tex-site) loads tex-site.el, which adds the
:override advice for `latex-mode' etc. An individual user in that site
who prefer built-in modes can get rid of AUCTeX by
     (unload-feature 'tex-site)
in the user init file. That's the way that AUCTeX satisfy the preference
of both site admins and individual users.

I briefly skimmed over info documents of Emacs and Elisp, but could not
find a description whether a site admin is allowed or not to alter the
value of user customize variable in site-start.el (not default.el, of
course).

If it isn't allowed, I'd request to turn defcustom into defconst (or a
similar facility for site admin to set up the site default mapping
between (A) and (B)) so that AUCTeX can continue to satisfy both site
admins and users without :override advice hack.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #20 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58075 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Wed, 28 Sep 2022 13:29:57 -0400

Ikumi Keita [2022-09-28 17:15:43] wrote:
> Hi Stefan,
>>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> So instead I suggest consider the current settings as being our
>> implementation of (A), and add (B) as some "mode remapping" layer to
>> decide which major mode to actually for a given "type/mode".
>> So instead of
>
>>     (defalias 'perl-mode #'cperl-mode)
>
>> We could have
>
>>     (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))
>
> In your proposed patch, `major-mode-remap-alist' is a user option
> defined by `defcustom'.
>
> Is it supposed to be legitimate that a site administrator sets up the
> default mapping for the site as
>>     (add-to-list 'major-mode-remap-alist '(perl-mode . cperl-mode))
> in site-start.el?

That's a somewhat general problem we have, indeed: if the
`site-start.el` file uses `add-to-list` this way, then Custom will think
the variable is "changed outside of Custom" and it will complain about
it if the user then tries to configure the var via Custom.

Using `defvar` instead of `defcustom` wouldn't really help tho: the user
still would not be able to configure it via Custom.

To work "properly", `site-start.el` would need to change the *default*
definition of the var (which Custom stores in the `standard-value`
property), and then ask Custom to re-evaluate the var's value.

Emacs *should* provide some convenient way to do that, but Someone™
needs to code it up.

> I briefly skimmed over info documents of Emacs and Elisp, but could not
> find a description whether a site admin is allowed or not to alter the
> value of user customize variable in site-start.el (not default.el, of
> course).

It's allowed and very common in practice (e.g. to
set `send-mail-function` or `smtpmail-smtp-server`).
But doing it will tend to cause the problems mentioned above.


        Stefan

Message #23 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 58075 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Thu, 29 Sep 2022 13:58:58 +0900

>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> To work "properly", `site-start.el` would need to change the *default*
> definition of the var (which Custom stores in the `standard-value`
> property), and then ask Custom to re-evaluate the var's value.

> Emacs *should* provide some convenient way to do that, but Someone™
> needs to code it up.

>> I briefly skimmed over info documents of Emacs and Elisp, but could not
>> find a description whether a site admin is allowed or not to alter the
>> value of user customize variable in site-start.el (not default.el, of
>> course).

> It's allowed and very common in practice (e.g. to
> set `send-mail-function` or `smtpmail-smtp-server`).
> But doing it will tend to cause the problems mentioned above.

Thank you. Then AUCTeX would do just add-to-list at initialize when
`major-mode-remap-alist' is available.

> Using `defvar` instead of `defcustom` wouldn't really help tho: the user
> still would not be able to configure it via Custom.

I personally don't feel that defcustom is much suitable for this kind of
configuration variable, i.e. an alist which may be given site-wide
default values by site admins. Suppose that a user who prefers built-in
TeX modes customized `major-mode-remap-alist' via Custom to invalidate
site-wide default TeX modes and the site admin adds an entry (perl-mode .
cperl-mode) later. Then the user doesn't see the new site-wide default
perl mode.
I have an impression that it's always suitable to use `add-to-list' and
`delete' (or `assq'+`delq') to manipulate such alists.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #26 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58075 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Thu, 29 Sep 2022 08:18:43 -0400

> Suppose that a user who prefers built-in TeX modes customized
> `major-mode-remap-alist' via Custom to invalidate site-wide default
> TeX modes and the site admin adds an entry (perl-mode .  cperl-mode)
> later. Then the user doesn't see the new site-wide default perl mode.

Indeed, it's a long-standing problem that Customize doesn't let the user
say "I want to add/remove <ELEM>" rather than "I want to set this list to
<VAL>".  Actually, strictly speaking it does, but noone bothered to make
that work well.


        Stefan

Message #29 received at 58075 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58075 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58075: Mapping file types to major modes
Date: Mon, 03 Oct 2022 11:18:13 -0400

Lars Ingebrigtsen [2022-09-27 14:54:59] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> And that doesn't account for the files where the mode is found by
>> `interpreter-mode-list`, by `mode:` cookies, etc...
> Yup.  So I think your proposed patch makes a lot of sense, so feel free
> to push.

Thanks, installed,


        Stefan

Message #34 received at 58075-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 58075-done <at> debbugs.gnu.org
Subject: Re: bug#58075: Mapping file types to major modes
Date: Mon, 03 Oct 2022 11:18:45 -0400

Closing

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.