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