[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35351: 27.0.50; Enable derived modes to run their own very-early 'ch
From: |
Phil Sainty |
Subject: |
bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code |
Date: |
Mon, 22 Apr 2019 20:16:33 +1200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Phil Sainty, 2019/04/20
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Phil Sainty, 2019/04/20
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Stefan Monnier, 2019/04/21
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code,
Phil Sainty <=
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Stefan Monnier, 2019/04/22
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Phil Sainty, 2019/04/22
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Phil Sainty, 2019/04/22
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Stefan Monnier, 2019/04/22
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Phil Sainty, 2019/04/22
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Stefan Monnier, 2019/04/23
- bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code, Stefan Monnier, 2019/04/22