bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code

[Phil Sainty <psainty@orcon.net.nz>]

On 22/04/19 8:54 AM, Stefan Monnier wrote:
> Usually this is done with something akin to:
>     (define-derived-mode my-actual-mode
>       ...)
>     (defun my-mode ()
>       (my-save-local-vars)
>       (my-actual-mode))
>
> or something similar (or not using define-derived-mode).
> Of course, this comes with its own drawbacks.

Yes, I think I like that least of all -- having the macro set up
everything based on a different name to the mode that people are
expected to be using just seems wrong to me.

I'd say the fact that there's a known "usual" hack for this
suggests that there's good reason to implement it directly in the
macro.


> Indeed what you're asking for is like a :before-hook symmetric

I've pushed an implementation to branch origin/fix/bug-35351 as a
starter.

https://git.savannah.gnu.org/cgit/emacs.git/log?h=fix/bug-35351

Previous Emacs versions will ignore the unrecognised keyword and
its value; so libraries using the new keyword and still wanting
to support older versions of Emacs can safely use the new keyword
and *conditionally* add advice when the Emacs version is < 27, to
run the same code before the mode function and achieve the same
effect.


> (FWIW, I think the "-hook" part of the name was probably not
> the best choice).

I've used the name :before-hook to match the existing
:after-hook, but we can certainly change it to something else.

(We could potentially deprecate the name :after-hook as well, and
add an alias for that with a better name at the same time.)

I'm now unsure whether :after-hook was intended to be interpreted
as "this is a bit like a *hook* which runs *after* everything
else has happened"; or if it meant "do this thing *after* the
mode *hook*" (or indeed after after-change-major-mode-hook).

The name ":before-hook" only really matches the former
interpretation.  ("before the mode hook" would be more
change-major-mode-after-body-hook than change-major-mode-hook).

Would :eval-before and :eval-after be good?


It might also be nice if symbol values for these keywords were
interpreted as the name of a function to call.  I don't think that
change would be *expected* to break anything, as a symbol value
would in effect be a no-op for the current :after-hook, and so
I wouldn't expect any existing modes to be using a symbol value.


In the initial commit I've used an approach which will run the
parent's :before-hook before the child's :before-hook, using the
change-major-mode-hook technique I mentioned at the end of my
original message, although I'm still uncertain about which order
is *best*.

Possibly it should be child-before-parent on the basis that the
author then has more influence over the order in which things
happen?  i.e.: If we implement it like this:

    ,child-before-hook
    (delay-mode-hooks
      (,(or parent 'kill-all-local-variables))

Which gives us the sequence:

    child-before-hook
    parent-before-hook
    change-major-mode-hook

Then child-before-hook could, if it wanted, do this:

    (add-hook 'change-major-mode-hook FOO nil :local)

And then FOO would run *after* the parent-before-hook,
effectively reversing that sequence.

(Whereas the code I've pushed initially is already using that
change-major-mode-hook approach, so there's no scope to
manipulate the order.)

Child-before-parent also means :before-hook *really is* the very
first thing that happens in the child mode, just as :after-hook
is the very last; so perhaps that's still a good/intuitive way
around, even if it's the reverse of the parent->child order used
in all the other phases of the mode's execution.

Child-before-parent would also match the order when 'before'
advice was being used to mimic the :before-hook behaviour in
older versions of Emacs.

I'm not sure I have a strong opinion on the matter, and the cases
in which it would even matter would be limited, but I think I've
now argued myself around to being slightly in favour of child-
before-parent; so if no one else has strong feelings about it,
I'll most likely change it to that.


-Phil