Re: Derived modes and mode hooks

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 9 Mar 2013 18:03:17 +0100
> From: Sebastian Wiesner <lunaryorn@gmail.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 2013/3/9 Eli Zaretskii <eliz@gnu.org>:
> >> Date: Sat, 9 Mar 2013 17:25:09 +0100
> >> From: Sebastian Wiesner <lunaryorn@gmail.com>
> >> Cc: emacs-devel <emacs-devel@gnu.org>
> >>
> >> 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's one possibility; I'm sure there are others, less radical ones.

> That sounds like a nasty hack to me.

I don't see why.  It is certainly not as nasty as overriding user
customizations.

> Also this only handles the case of auto-fill-mode…

You gave an example of a problem, I gave you an example of a solution.
My point being that there should be a similar solution for each such
problem.  IOW, someone already bumped into the same problems, and
provided solutions.  You just need to find them.  (And I'm not too
smart in this matter: I just looked in sgml.el.)

> 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?

I did read it, I just didn't understand it in full.  You were talking
about modes I know nothing about; you cannot expect me to study every
reference in what you say just to show how the same problems could be
solved differently.

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

The whole business of inheriting from a mode makes sense only when the
child mode is compatible with its parent.  If this is not so in too
many levels, then inheriting for such a parent is not what you want.
If a small number of user customizations don't make any sense in the
child mode, then using variables such as fill-nobreak-predicate is
_the_ way, and users will not blame you, because they understand why
e.g. filling makes no sense in some situations in your mode.

But futzing with user customizations _directly_, i.e. by changing
them, is a no-no in any case, IMO.

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

That's not what I said (there's nothing about "user's needs" in my
wording), but whatever.

> 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?

Feel free.