GNU bug report logs - #8158
Definition of auto-mode-alist

Previous Next

Package: emacs;

Reported by: Reuben Thomas <rrt <at> sc3d.org>

Date: Wed, 2 Mar 2011 22:03:01 UTC

Severity: wishlist

Fixed in version 29.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8158 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#8158: Definition of auto-mode-alist
Date: Thu, 21 Oct 2021 13:29:08 -0700
Stefan Monnier <monnier <at> 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.




This bug report was last modified 3 years and 119 days ago.

Previous Next


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