Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 Eli Zaretskii <address@hidden>:
>> 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?

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

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

I hitherto thought the main point of derived modes was simply to allow
re-use of code, and to provide a generic interface for customization,
i.e. save the user the PITA of enabling auto-fill-mode explicitly in
any plain text mode again.  Incidentally, the latter is the only
reason for deriving modes I could actually find in the Emacs Lisp
manual. See "Basic Major Modes":

“As far as possible, new major modes should be derived, either
directly or indirectly, from one of these three modes.  One reason is
that this allows users to customize a single mode hook (e.g.,
`prog-mode-hook') for an entire family of relevant modes (e.g., all
programming language modes).”

Note that there are no other reasons given, following this “one
reason”.  Moreover neither this node, nor "Derived Modes" claim that a
derived mode is supposed to be compatible to its parent mode.

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

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.