define-derived-mode runs parent mode hook after evaluating body

define-derived-mode runs parent mode hook after evaluating body

[martin rudalics]

A subtle bug with `define-derived-mode' I just met with
`change-log-mode'.  The latter's definition goes as ...

(define-derived-mode change-log-mode text-mode "Change Log"
   "..."
   (setq left-margin 8
	fill-column 74
         ...

...but in my .emacs I have:

(add-hook
  'text-mode-hook
  '(lambda () (setq fill-column 72)))

Consequently, my Change Log buffers have a `fill-column' of 72 which is
not really desirable.  I obviously don't have any intention to check
which of the major modes I eventually use derive from text-mode and add
the appropriate hooks there.

Is it really useful/needed to delay the hook of the parent mode in a
derived mode until after evaluating the body?

Re: define-derived-mode runs parent mode hook after evaluating body

[Stefan Monnier]

> Is it really useful/needed to delay the hook of the parent mode in a
> derived mode until after evaluating the body?

Yes.  It took a good bit of effort to do it, so yes, it is useful/needed.


        Stefan

Re: define-derived-mode runs parent mode hook after evaluating body

[Stefan Monnier]

> (define-derived-mode change-log-mode text-mode "Change Log"
>   "..."
>   (setq left-margin 8
> 	fill-column 74
>         ...

> ...but in my .emacs I have:

> (add-hook
>  'text-mode-hook
>  '(lambda () (setq fill-column 72)))

The problem here is that we use text-mode both as a parent and as a real
major-mode, so you can't change "text-mode" without changing all
its derivatives.

Maybe the real text-mode should be renamed to plain-text-mode (and derive
from text-mode, of course).


        Stefan

Re: define-derived-mode runs parent mode hook after evaluating body

[martin rudalics]

 >>(define-derived-mode change-log-mode text-mode "Change Log"
 >>  "..."
 >>  (setq left-margin 8
 >>	fill-column 74
 >>        ...
 >
 >
 >>...but in my .emacs I have:
 >
 >
 >>(add-hook
 >> 'text-mode-hook
 >> '(lambda () (setq fill-column 72)))
 >
 >
 > The problem here is that we use text-mode both as a parent and as a real
 > major-mode, so you can't change "text-mode" without changing all
 > its derivatives.
 >
 > Maybe the real text-mode should be renamed to plain-text-mode (and derive
 >>from text-mode, of course).

Which would solve this special case.  In general, however, I want to add
something to a parent-mode hook and pass it on to its derivatives unless
the derivatives have their own opinion about that.  Well, I could do

(add-hook
  'text-mode-hook
  '(lambda ()
     (unless (and (local-variable-p 'fill-column)
		 (not (equal fill-column
			     (default-value 'fill-column))))
       (setq fill-column 72))))

but this strikes me as inconvenient, ugly, and maybe faulty.

Re: define-derived-mode runs parent mode hook after evaluating body

[Richard Stallman]

    > Is it really useful/needed to delay the hook of the parent mode in a
    > derived mode until after evaluating the body?

    Yes.  It took a good bit of effort to do it, so yes, it is useful/needed.

Do you remember the sort of problems which we solved with this?

Re: define-derived-mode runs parent mode hook after evaluating body

[Stefan Monnier]

>> Is it really useful/needed to delay the hook of the parent mode in a
>> derived mode until after evaluating the body?

>     Yes.  It took a good bit of effort to do it, so yes, it is useful/needed.

> Do you remember the sort of problems which we solved with this?

Customizations that need to modify variable settings based on the
major-mode's value (e.g. add an element to a list).
Or customizations that depend on the major mode's variable settings
(e.g. font-lock-mode, which if turned ON too early tends to use the
font-lock-keywords of the parent mode rather than the child's, although
this particular case was worked around specifically because just fixing
define-derived-mode wasn't sufficient).


        Stefan

Re: define-derived-mode runs parent mode hook after evaluating body

[Stefan Monnier]

> Which would solve this special case.  In general, however, I want to add
> something to a parent-mode hook and pass it on to its derivatives unless
> the derivatives have their own opinion about that.  Well, I could do

> (add-hook
>  'text-mode-hook
>  '(lambda ()
>     (unless (and (local-variable-p 'fill-column)
> 		 (not (equal fill-column
> 			     (default-value 'fill-column))))
>       (setq fill-column 72))))

Other than spurious quote in front of the lambda, this looks fine to me.
More specifically it says in Elisp basically the same as what you said above
in English, so it seems to be The Right Thing.

> but this strikes me as inconvenient, ugly, and maybe faulty.

The problem is that if what you want to do is "always add 4 to fill-column",
the current behavior allows you to do that whereas your suggestion to run
the parent mode early would preclude it.


        Stefan

Re: define-derived-mode runs parent mode hook after evaluating body

[Richard Stallman]

    > Do you remember the sort of problems which we solved with this?

    Customizations that need to modify variable settings based on the
    major-mode's value (e.g. add an element to a list).
    Or customizations that depend on the major mode's variable settings

Ah, yes.  Those cases have not disappeared, and we do still need to
delay the mode hooks.  Although delaying mode hook would give the
desired results in this case, we can't solve the problem that way.

So what should we recommend in a case like this?

One possible recommendation is that the hook function should test
major-mode and do nothing if it is not `text-mode'.  That way it won't
affect the derived modes at all.  Or it could test (memq major-mode
LIST-OF-OK-MODES) or (memq major-mode LIST-OF-EXCEPTIONS).

Re: define-derived-mode runs parent mode hook after evaluating body

[martin rudalics]

 >>(add-hook
 >> 'text-mode-hook
 >> '(lambda ()
 >>    (unless (and (local-variable-p 'fill-column)
 >>		 (not (equal fill-column
 >>			     (default-value 'fill-column))))
 >>      (setq fill-column 72))))
 >
 >
 > Other than spurious quote in front of the lambda, this looks fine to me.
 > More specifically it says in Elisp basically the same as what you said above
 > in English, so it seems to be The Right Thing.

It works when the derived mode sets a buffer-local variable.  I wouldn't
know what to do for normal variables though - maybe a non-problem.

 >>but this strikes me as inconvenient, ugly, and maybe faulty.
 >
 >
 > The problem is that if what you want to do is "always add 4 to fill-column",
 > the current behavior allows you to do that whereas your suggestion to run
 > the parent mode early would preclude it.

Hmmm .... the parent mode runs early in any case.  Do we really want its
hooks to add 4 to something defined in the body of the derived mode?
What if a hook of the derived mode wants to add another four?  Do we add
eight?

martin, who never wanted to "suggest" anything in this context.