Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 Eli Zaretskii <address@hidden>:
>> Date: Sat, 9 Mar 2013 17:25:09 +0100
>> From: Sebastian Wiesner <address@hidden>
>> Cc: emacs-devel <address@hidden>
>>
>> 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".
>
> See fill-nobreak-predicate.  You can use that, and then automatic
> filling will work correctly for HTML.

In order to completely disable automatic filling I'd add a function
which simply returns t to this list?  That sounds like a nasty hack to
me.  Also this only handles the case of auto-fill-mode…

By the way, I did not talk about filling HTML, but I guess it just
wasn't your “bloody business” to read my mail carefully, was it?

>> > 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.
>
> It is not any bloody business of a mode author to override
> customizations of users.

I'm talking overriding customization *in the special case*, that a
customization for a *parent mode* (which the user most likely did
without caring for, or even knowing of, a specific derived mode) is
*not reasonably applicable* in a derived mode, for the sake of
convenience for the users of the derived mode.

But please ignore this objection of mine, I rather thank you
wholeheartedly for ignoring this specific special case and instead
giving me the perfect excuse of an Emacs authority stating that it's
not my “bloody business” to care for my user's needs.  In case any
user of my mode foolishly fails to understand this special notion of
Emacs development, may I forward her to your mail address, for special
guidance on the latest and greatest Emacs development practices?