bug#8158: Definition of auto-mode-alist

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

A comment in files.el says:

  ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
  ;; c++-mode, java-mode and more) are added through autoload
  ;; directives in that file.  That way is discouraged since it
  ;; spreads out the definition of the initial value.

Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?

If the maintainers agree, then the last sentence should be changed to
encourage the removal of the initial values back into the relevant
mode files.

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Wed, Mar 2, 2011 at 11:02 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> A comment in files.el says:
>
>  ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>  ;; c++-mode, java-mode and more) are added through autoload
>  ;; directives in that file.  That way is discouraged since it
>  ;; spreads out the definition of the initial value.
>
> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?
>
> If the maintainers agree, then the last sentence should be changed to
> encourage the removal of the initial values back into the relevant
> mode files.

I think I disagree. This sort of information must be coordinated so it
need to be in a central place.

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 2 March 2011 22:18, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Wed, Mar 2, 2011 at 11:02 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>> A comment in files.el says:
>>
>>  ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>>  ;; c++-mode, java-mode and more) are added through autoload
>>  ;; directives in that file.  That way is discouraged since it
>>  ;; spreads out the definition of the initial value.
>>
>> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?
>>
>> If the maintainers agree, then the last sentence should be changed to
>> encourage the removal of the initial values back into the relevant
>> mode files.
>
> I think I disagree. This sort of information must be coordinated so it
> need to be in a central place.

Why does it have to be coordinated? The most obvious reason seems to
me "to avoid clashes", but this is detectable by parsing
auto-mode-alist. Generating a warning when there are clashing settings
for the same suffix would also be handy for 3rd party modes, which
cannot integrate their information in this way.

For modes that are part of Emacs, this system is fragile, as it's easy
to forget that part of the mode is in files.el.

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Wed, Mar 2, 2011 at 11:22 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 2 March 2011 22:18, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Wed, Mar 2, 2011 at 11:02 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>>> A comment in files.el says:
>>>
>>>  ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>>>  ;; c++-mode, java-mode and more) are added through autoload
>>>  ;; directives in that file.  That way is discouraged since it
>>>  ;; spreads out the definition of the initial value.
>>>
>>> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?
>>>
>>> If the maintainers agree, then the last sentence should be changed to
>>> encourage the removal of the initial values back into the relevant
>>> mode files.
>>
>> I think I disagree. This sort of information must be coordinated so it
>> need to be in a central place.
>
> Why does it have to be coordinated? The most obvious reason seems to
> me "to avoid clashes", but this is detectable by parsing
> auto-mode-alist. Generating a warning when there are clashing settings
> for the same suffix would also be handy for 3rd party modes, which
> cannot integrate their information in this way.

There are not only file extension clashes (which I suppose is what you
think of), but also mode selection clashes.

I think the control of this must be given to the user and that
requires a central system. The current system is not optimal however.
I have tried to implement an addition to it in majmodpri.el in nXhtml.
"majmodpri" stands for "major modes priorities" and that is just what
it implements. (The implementation is not as easy to use as I would
like it to be. Customization features for lists in Emacs is lacking a
lot of functionalities IMO.)

> For modes that are part of Emacs, this system is fragile, as it's easy
> to forget that part of the mode is in files.el.

This is true and perhaps part of the implementation should actually be
distributed. However it must then be implemented in a way that still
leaves control to the user. Just loading a new elisp file should not
override old choices. (See above for clarification.)

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 2 March 2011 22:30, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> I think the control of this must be given to the user and that
> requires a central system.

From the point of view of the user, the system is centralised:
auto-mode-alist and friends, which can be redefined at will.

> Just loading a new elisp file should not
> override old choices. (See above for clarification.)

Sure, but autoloaded lines from mode files aren't rerun when the mode
is loaded, are they? (At least, it seems not, because modes I have
autoloaded still only have one entry per file suffix in
auto-mode-alist.)

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Wed, Mar 2, 2011 at 11:35 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 2 March 2011 22:30, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>
>> I think the control of this must be given to the user and that
>> requires a central system.
>
> From the point of view of the user, the system is centralised:
> auto-mode-alist and friends, which can be redefined at will.
>
>> Just loading a new elisp file should not
>> override old choices. (See above for clarification.)
>
> Sure, but autoloaded lines from mode files aren't rerun when the mode
> is loaded, are they? (At least, it seems not, because modes I have
> autoloaded still only have one entry per file suffix in
> auto-mode-alist.)

So you mean that the insertion into auto-mode-alist should be done by
autoloading? I think that is too fragile since it will depend on how
modules are loading.

As I said in a previous message the user must be given some simple
control of this. In my opinion that means that some way to prioritize
must be used, please see my previous message. That would allow for
decentralized additions to auto-mode-alist (but you seem to have
missed that point?).

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 2 March 2011 23:14, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> So you mean that the insertion into auto-mode-alist should be done by
> autoloading? I think that is too fragile since it will depend on how
> modules are loading.

I am only saying that this is what seems to happen at the moment, and
I have no problem with it.

> As I said in a previous message the user must be given some simple
> control of this. In my opinion that means that some way to prioritize
> must be used, please see my previous message.

The user already has a way to prioritize, by removing or adding
elements of auto-mode-alist as they see fit, in their .emacs or
equivalent. When this is run, emacs has already initialised
auto-mode-alist from autoloads, so they will not disturb the user's
settings.

> That would allow for
> decentralized additions to auto-mode-alist (but you seem to have
> missed that point?).

I may have missed the point, but as far as I can see, everything you
want to do can be achieved with the current system, and decentralising
the initialisation of auto-mode-alist would not change that: I have no
problems with my auto-mode-alist from modes whose settings are not
centralised.

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Thu, Mar 3, 2011 at 12:21 AM, Reuben Thomas <rrt@sc3d.org> wrote:
>
>> As I said in a previous message the user must be given some simple
>> control of this. In my opinion that means that some way to prioritize
>> must be used, please see my previous message.
>
> The user already has a way to prioritize, by removing or adding
> elements of auto-mode-alist as they see fit, in their .emacs or
> equivalent. When this is run, emacs has already initialised
> auto-mode-alist from autoloads, so they will not disturb the user's
> settings.
>
>> That would allow for
>> decentralized additions to auto-mode-alist (but you seem to have
>> missed that point?).
>
> I may have missed the point, but as far as I can see, everything you
> want to do can be achieved with the current system, and decentralising
> the initialisation of auto-mode-alist would not change that: I have no
> problems with my auto-mode-alist from modes whose settings are not
> centralised.

Yes, you have missed it. I wrote majmodpri.el to get around the
problem that some elisp files added things to auto-mode-alist. I got
some bug reports for nXhtml from some of those users.

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 2 March 2011 23:39, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> Yes, you have missed it. I wrote majmodpri.el to get around the
> problem that some elisp files added things to auto-mode-alist.

So, are you saying that elisp files with non-centralized settings
which are part of Emacs were causing you problems?

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Thu, Mar 3, 2011 at 12:41 AM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 2 March 2011 23:39, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>
>> Yes, you have missed it. I wrote majmodpri.el to get around the
>> problem that some elisp files added things to auto-mode-alist.
>
> So, are you saying that elisp files with non-centralized settings
> which are part of Emacs were causing you problems?

Not me, but a lot of other people.

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 2 March 2011 23:42, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 12:41 AM, Reuben Thomas <rrt@sc3d.org> wrote:
>> On 2 March 2011 23:39, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>
>>> Yes, you have missed it. I wrote majmodpri.el to get around the
>>> problem that some elisp files added things to auto-mode-alist.
>>
>> So, are you saying that elisp files with non-centralized settings
>> which are part of Emacs were causing you problems?
>
> Not me, but a lot of other people.

Sorry, let me try again.

Are you saying that elisp files shipped as part of Emacs, with
non-centralized settings, were causing your users problems?

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Lennart Borgman]

On Thu, Mar 3, 2011 at 12:43 AM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 2 March 2011 23:42, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Thu, Mar 3, 2011 at 12:41 AM, Reuben Thomas <rrt@sc3d.org> wrote:
>>> On 2 March 2011 23:39, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>
>>>> Yes, you have missed it. I wrote majmodpri.el to get around the
>>>> problem that some elisp files added things to auto-mode-alist.
>>>
>>> So, are you saying that elisp files with non-centralized settings
>>> which are part of Emacs were causing you problems?
>>
>> Not me, but a lot of other people.
>
> Sorry, let me try again.
>
> Are you saying that elisp files shipped as part of Emacs, with
> non-centralized settings, were causing your users problems?

No. It is only with third party files I have seen the problem (since
files shipped with Emacs currently does not change auto-mode-alist
when they are loaded).

bug#8158: Definition of auto-mode-alist

[Reuben Thomas]

On 3 March 2011 00:30, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 12:43 AM, Reuben Thomas <rrt@sc3d.org> wrote:
>> On 2 March 2011 23:42, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>> On Thu, Mar 3, 2011 at 12:41 AM, Reuben Thomas <rrt@sc3d.org> wrote:
>>>> On 2 March 2011 23:39, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>>
>>>>> Yes, you have missed it. I wrote majmodpri.el to get around the
>>>>> problem that some elisp files added things to auto-mode-alist.
>>>>
>>>> So, are you saying that elisp files with non-centralized settings
>>>> which are part of Emacs were causing you problems?
>>>
>>> Not me, but a lot of other people.
>>
>> Sorry, let me try again.
>>
>> Are you saying that elisp files shipped as part of Emacs, with
>> non-centralized settings, were causing your users problems?
>
> No. It is only with third party files I have seen the problem (since
> files shipped with Emacs currently does not change auto-mode-alist
> when they are loaded).

Right, but Emacs does not have fully centralized settings. (Many modes
set their own auto-mode-alist entries.) So changing things within
Emacs does not affect your problem.

-- 
http://rrt.sc3d.org

bug#8158: Definition of auto-mode-alist

[Stefan Monnier]

>   ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>   ;; c++-mode, java-mode and more) are added through autoload
>   ;; directives in that file.  That way is discouraged since it
>   ;; spreads out the definition of the initial value.

> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?

I agree, but I think Richard disagrees.  Also, order of entries in
auto-mode-alist can be important, so autoloading those entries does not
work for all cases.  But for 90% of the cases, it's perfectly fine and
indeed we do use it already in several cases.

Such ordering conflicts are difficult to detect automatically: detecting
them when we compile Emacs requires checking which regexps overlap
(which is perfectly doable in theory, but we'd need a "regexp-to-DFA
compiler" for that, basically), detecting them at run-time is too late
(often it'd be wrong to ask the user to resolve such conflicts).


        Stefan

bug#8158: Definition of auto-mode-alist

[Stefan Monnier]

> So you mean that the insertion into auto-mode-alist should be done by
> autoloading? I think that is too fragile since it will depend on how
> modules are loading.

Then we need to autoload something like an `add-to-list' supplemented
with some ordering info.


        Stefan

bug#8158: Definition of auto-mode-alist

[Stefan Kangas]

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

>>   ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>>   ;; c++-mode, java-mode and more) are added through autoload
>>   ;; directives in that file.  That way is discouraged since it
>>   ;; spreads out the definition of the initial value.
>
>> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?
>
> I agree, but I think Richard disagrees.  Also, order of entries in
> auto-mode-alist can be important, so autoloading those entries does not
> work for all cases.  But for 90% of the cases, it's perfectly fine and
> indeed we do use it already in several cases.
>
> Such ordering conflicts are difficult to detect automatically: detecting
> them when we compile Emacs requires checking which regexps overlap
> (which is perfectly doable in theory, but we'd need a "regexp-to-DFA
> compiler" for that, basically), detecting them at run-time is too late
> (often it'd be wrong to ask the user to resolve such conflicts).

Does anyone object to just removing the above comment?  And similarly
for `interpreter-mode-alist', I suppose.

bug#8158: Definition of auto-mode-alist

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Does anyone object to just removing the above comment?  And similarly
> for `interpreter-mode-alist', I suppose.

I think removing the comment is fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8158: Definition of auto-mode-alist

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I agree, but I think Richard disagrees.

What is the question that maybe I disagree about?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#8158: Definition of auto-mode-alist

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > > I agree, but I think Richard disagrees.
>
> What is the question that maybe I disagree about?

The full initial message was:

> A comment in files.el says:
>
>   ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
>   ;; c++-mode, java-mode and more) are added through autoload
>   ;; directives in that file.  That way is discouraged since it
>   ;; spreads out the definition of the initial value.
>
> Isn't this a bit unmodular as Emacs continues to grow, and given loaddefs.el?
>
> If the maintainers agree, then the last sentence should be changed to
> encourage the removal of the initial values back into the relevant
> mode files.

What I propose is to make no concrete change besides removing that
comment.  This avoids people rushing off to change everything around,
which is probably not what we want at this point, but also doesn't very
strongly discourage a more modular design.  If any problems crop up, we
can address them with specific fixes.

bug#8158: Definition of auto-mode-alist

[Stefan Kangas]

close 8158 29.1
thanks

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Does anyone object to just removing the above comment?  And similarly
>> for `interpreter-mode-alist', I suppose.
>
> I think removing the comment is fine.

No further comments here within 3 months, so I've now installed the
below change on master.

diff --git a/lisp/files.el b/lisp/files.el
index aabe8f445e..4ba71e6144 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -2757,8 +2757,7 @@ auto-mode-case-fold
 (defvar auto-mode-alist
   ;; Note: The entries for the modes defined in cc-mode.el (c-mode,
   ;; c++-mode, java-mode and more) are added through autoload
-  ;; directives in that file.  That way is discouraged since it
-  ;; spreads out the definition of the initial value.
+  ;; directives in that file.
   (mapcar
    (lambda (elt)
      (cons (purecopy (car elt)) (cdr elt)))
@@ -3056,8 +3055,7 @@ conf-mode-maybe
 (defvar interpreter-mode-alist
   ;; Note: The entries for the modes defined in cc-mode.el (awk-mode
   ;; and pike-mode) are added through autoload directives in that
-  ;; file.  That way is discouraged since it spreads out the
-  ;; definition of the initial value.
+  ;; file.
   (mapcar
    (lambda (l)
      (cons (purecopy (car l)) (cdr l)))