Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 Stefan Monnier <address@hidden>:
> It can't (well, if it really really wants to, it can add some code to
> its own foo-mode-hook which is run after text-mode-hook).

That's unfortunate.

> A function added to a mode hook takes precedence, because it's presumably
> a user choice, whereas body-of-foo-mode is the choice of code's author.

I can understand the rationale for this design, but I find it too
limited:  A *more specific* mode cannot overrule the customization of
*more generic* modes, even if the customization for the generic mode
doesn't make sense, or is even dangerous, in the more specific mode.

To give a concrete example for such a case:  The phpbb forum software
translates line breaks in the BB Code markup of posts into line breaks
in the HTML rendering, i.e. line breaks in the markup of a posting
directly affect its visual representation.  Hence, automatic filling
is a no-go, and I want to disable by default in this mode, even if the
user has enabled it generically by the common way of adding it to
"text-mode-hook".

I cannot do so now, but instead have to burden the user with the
responsibility to get the customization right for my mode.  To the
user this means that one cannot simply enable auto filling generically
for all text modes and be on the safe side.  Instead she has to check
whether the mode works well with auto filling, and maintain an
explicit black- or whitelist in her Init file, which is rather
cumbersome imho.

> If the user doesn't want auto-fill-mode in foo-mode, she can add to
> foo-mode-hook to turn auto-fill-mode off, or she can change her
> text-mode-hook to test (derived-mode-p 'foo-mode) before enabling
> auto-fill-mode.

I am not talking about users here, I am talking about the needs of
major mode *authors*, who may wish to disable dangerous settings in
their modes, even if that includes overruling some of the user's
customizations for *more generic* modes.