Derived modes and mode hooks

Derived modes and mode hooks

[Sebastian Wiesner]

Hello,

if I understand the documentation of derived modes [1] aright, *all*
hooks (including parent mode hooks) are run *after* the body of the
derived mode.  For instance, given "foo-mode" defined as:

(define-derived-mode foo-mode text-mode "Foo"
  "A useless mode for demonstration purposes"
  (body-of-foo-mode))

Then "M-x foo-mode" will

1. Perform some standard setup stuff (e.g. killing local variables,
setting the key map, etc.)
2. Execute "body-of-foo-mode"
3. Execute all hooks in "text-mode-hook"
4. Execute all hooks in "foo-mode-hook"

Is this right?  If so, how can `body-of-foo-mode` forcibly overrule
settings made in `text-mode-hook`?

For instance, assume that the user has "(add-hook 'text-mode-hook
'auto-fill-mode)" in her init file (a very common setting I presume),
how can "foo-mode" "body-of-foo-mode" forcibly disable
"auto-fill-mode"?

Greetings,
Sebastian Wiesner

[1]: http://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html

Re: Derived modes and mode hooks

[Xue Fuqiao]

On Sat, 9 Mar 2013 15:06:00 +0100
Sebastian Wiesner <lunaryorn@gmail.com> wrote:

> For instance, given "foo-mode" defined as:
> 
> (define-derived-mode foo-mode text-mode "Foo"
>   "A useless mode for demonstration purposes"
>   (body-of-foo-mode))

> Then "M-x foo-mode" will

> 1. Perform some standard setup stuff (e.g. killing local variables,
> setting the key map, etc.)
> 2. Execute "body-of-foo-mode"
> 3. Execute all hooks in "text-mode-hook"
> 4. Execute all hooks in "foo-mode-hook"

> Is this right?  If so, how can `body-of-foo-mode` forcibly overrule
> settings made in `text-mode-hook`?

See the function `run-mode-hooks'.  I'm no expert on this, but IIRC
`after-change-major-mode-hook' helps.

-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 Xue Fuqiao <xfq.free@gmail.com>:
> On Sat, 9 Mar 2013 15:06:00 +0100
> Sebastian Wiesner <lunaryorn@gmail.com> wrote:
>
>> For instance, given "foo-mode" defined as:
>>
>> (define-derived-mode foo-mode text-mode "Foo"
>>   "A useless mode for demonstration purposes"
>>   (body-of-foo-mode))
>
>> Then "M-x foo-mode" will
>
>> 1. Perform some standard setup stuff (e.g. killing local variables,
>> setting the key map, etc.)
>> 2. Execute "body-of-foo-mode"
>> 3. Execute all hooks in "text-mode-hook"
>> 4. Execute all hooks in "foo-mode-hook"
>
>> Is this right?  If so, how can `body-of-foo-mode` forcibly overrule
>> settings made in `text-mode-hook`?
>
> See the function `run-mode-hooks'.

What am I supposed to see there?

I read the documentation of this function, even looked at its source
code, and now I feel confirmed in my analysis of things.  But I can't
see anything that would help me to solve the actual problem, that is
forcibly disabling `auto-fill-mode`.  I can't even control when and
how this function is invoked, as `define-derived-mode` does that
implicitly.

>  I'm no expert on this, but IIRC `after-change-major-mode-hook' helps.

Call me stupid, but I fail to see how it could.  It's executed even
earlier than `body-of-foo-mode`, and thus suffers from the same
problem:  The later execution of `text-mode-hook` will bring back
`auto-fill-mode`, given `(add-hook 'text-mode-hook
'auto-fill-mode)` in the user's init file.

I need something that runs *after* `text-mode-hook`, but *before*
`foo-mode-hook`.

Re: Derived modes and mode hooks

[Stefan Monnier]

> Is this right?  If so, how can `body-of-foo-mode` forcibly overrule
> settings made in `text-mode-hook`?

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

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.

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.


        Stefan

Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 Stefan Monnier <monnier@iro.umontreal.ca>:
> 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.

Re: Derived modes and mode hooks

[Eli Zaretskii]

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

> I cannot do so now, but instead have to burden the user with the
> responsibility to get the customization right for my mode.

No, you don't, see above.

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

Re: Derived modes and mode hooks

[Sebastian Wiesner]

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

Re: Derived modes and mode hooks

[Eli Zaretskii]

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

Re: Derived modes and mode hooks

[Sebastian Wiesner]

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?

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

Re: Derived modes and mode hooks

[Eli Zaretskii]

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

Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/9 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?

Truly, you said so, yet the only less radical (or say, less convoluted
way) I see is simply disabling the mode, which I thought you were
opposing.  However, we obviously misunderstood each other, see below.

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

I don't indent do that.

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

I never meant to modify the hook itself.  I agree that this is a total no-go.

I merely intend to disable a specific minor mode (i.e. auto-fill-mode)
in a specific major mode derived from text mode, for good reasons.  I
tried to do that in the body of the derived mode, only to discover
that all hooks are run *after* the evaluation of the body, making my
attempt pointless in face of the common way of enabling auto-fill-mode
by adding it to text-mode-hook.  Hence my initial mail.

However, I see that there is no reasonable way to achieve this, so
I'll simply tell my users to do so.  Not as convenient as I had
wished, but apparently the only reasonable way.

Re: Derived modes and mode hooks

[chad]

On 09 Mar 2013, at 11:49, Sebastian Wiesner <lunaryorn@gmail.com> wrote:
> However, I see that there is no reasonable way to achieve this, so
> I'll simply tell my users to do so.  Not as convenient as I had
> wished, but apparently the only reasonable way.

If you're sure that auto-fill never makes sense in foo-mode,  you
can seed foo-mode-hook with turn-off-auto-fill (and mention such
in your documentation), can't you?

~Chad

Re: Derived modes and mode hooks

[Stefan Monnier]

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

Yes, that's unfortunate.

You're going to need to be inventive in order to reconcile the fact that
you want to derive from text-mode while at the same time writing a mode
that behaves differently from what text-mode expects.

Eli's suggestion might work, tho it's admittedly crude.
Maybe you can set normal-auto-fill-function buffer-locally.
Or you can set auto-fill-mode-hook buffer-locally.
Or you can set the fill-column to a very large number.
Or (as mentioned) you can set phpbb-mode-hook's default to disable
auto-fill-mode.
There are probably other options.


        Stefan

Re: Derived modes and mode hooks

[Sebastian Wiesner]

2013/3/10 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 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".
>
> Yes, that's unfortunate.
>
> You're going to need to be inventive in order to reconcile the fact that
> you want to derive from text-mode while at the same time writing a mode
> that behaves differently from what text-mode expects.
>
> Eli's suggestion might work, tho it's admittedly crude.
> Maybe you can set normal-auto-fill-function buffer-locally.
> Or you can set auto-fill-mode-hook buffer-locally.
> Or you can set the fill-column to a very large number.
> Or (as mentioned) you can set phpbb-mode-hook's default to disable
> auto-fill-mode.
> There are probably other options.

Much thanks for your help.  I think I'll just add "turn-off-auto-fill"
to the mode hook.

Sebastian Wiesner