Re: Derived modes and mode hooks

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 9 Mar 2013 19:58:11 +0100
> From: Sebastian Wiesner <lunaryorn@gmail.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 2013/3/9 Eli Zaretskii <eliz@gnu.org>:
> >> 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.
> 
> So your proposed solution effectively inhibits auto filling and thus
> also *effectively overrides* the user's customization, but in a
> convoluted way, abusing a variable which is obviously intended for a
> different purpose, and which most likely only few users even know
> about.
> 
> Yet you actually *prefer* this crude way of effectively overriding the
> user's customization over simply disabling the mode, *the* obvious way
> of inhibiting auto filling, more over clearly indicated to the user by
> the absence of the corresponding entry in the mode line.
> 
> Did I get that correctly?

No.  I did say I'm sure there are less radical ways of doing this,
didn't I?

> > The whole business of inheriting from a mode makes sense only when the
> > child mode is compatible with its parent.
> 
> I wonder how you define “compatible”, for I cannot see any applicable
> definition of this term that would make plain "text-mode" and an
> advanced mode like AUCTeX' "latex-mode" “compatible”.  They behave
> completely different, and I doubt that any *user* of AUCTeX would
> actually call them “compatible”.

They are "compatible" because TeX documents are plain text documents,
albeit with markup.

> I hitherto thought the main point of derived modes was simply to allow
> re-use of code

Reuse doesn't make sense if you need to disable most of the inherited
code.  Might as well write your mode from scratch in that case.

> I do not want to *change* the user's customization.  The user's
> customization will still be in effect, where it makes sense, i.e. in
> other modes derived from text-mode.

Customizations made to FOO-mode-hook are supposed to be in effect in
any mode which inherits from FOO.

In any case, you misunderstand what I meant: I meant not to modify the
hook itself.  It is okay to make the same effect in other ways.