bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth

[Lars Ingebrigtsen <larsi@gnus.org>]

Philipp Stephani <p.stephani2@gmail.com> writes:

> The order isn't undefined, and add-hook carefully distinguishes
> between negative and nonnegative depths in this case. It's just that
> the relative ordering of depths with the same sign but different
> "localness" isn't considered/documented.

That's a different way to say "undefined".  :-)

If I'm reading run_hook_with_args correctly, it'll loop over the local
hook first (in order), and when it happens upon a t in that value, it'll
then loop over the global value (in order), and then finish up the rest
of the local ones.

> How about documenting something along those lines?
> In "Running hooks", amend the paragraph
> "If the hook variable is buffer-local, the buffer-local variable will
> be used instead of the global variable.  However, if the buffer-local
> variable contains the element @code{t}, the global hook variable will
> be run as well."
> to say that the global hook is run at exactly the place where the "t" appears.

(Oh, I should have read your entire mail before starting to answer.)

Well, you're still not saying that that's what'll happen with the t.
And I'm not sure that's really a conscious design, but just an odd
implementation. 

> In "Setting hooks", amend the paragraph
> "If @var{local} is non-@code{nil}, that says to add @var{function} to the
> buffer-local hook list instead of to the global hook list.  This makes
> the hook buffer-local and adds @code{t} to the buffer-local value."
> to specify where the "t" is added (IIUC it's appended if depth > 0 and
> prepended otherwise).

I think I'd just prefer to say that the ordering is undefined if you
have both a global and a local hook.  Either that, or actually implement
a proper ordering system, because "do the global where the t is" is very
odd and somewhat brittle.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no