GNU bug report logs - #48584
28.0.50; Incorrect hook ordering between local and global hooks with depth

Previous Next

Full log

Message #23 received at 48584 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48584 <at> debbugs.gnu.org
Subject: Re: bug#48584: 28.0.50; Incorrect hook ordering between local and
 global hooks with depth
Date: Mon, 5 Jul 2021 20:37:16 +0200

> Am 06.06.2021 um 11:12 schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
> 
> Philipp <p.stephani2 <at> gmail.com> writes:
> 
>>> 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.
>> 
>> Yes - and that's a reasonable behavior to expect, and we should document it.
> 
> I think it's an implementation detail that users should not depend on.
> Where that `t' ends up being depends on many subtle things like the
> order of your add-hook/remove-hook calls in your .emacs file.

What we think about this doesn't matter much.  As I explained, people depend on observable/observed behavior.

Besides, hook ordering for abnormal hooks is crucial, so we can't just say "don't depend on it."

> 
>> Correct hook ordering is crucial for abnormal hooks.  We already rely
>> on the very specific ordering behavior several times in the Emacs
>> codebase alone.  I've searched a bit through the Emacs codebase, and
>> found the following places where Emacs runs an abnormal hook with
>> `run-hook-with-args-until-success/failure' that also gains a local
>> part somewhere the codebase:
> 
> [...]
> 
>> That is, we rely on this "undefined" behavior already in very basic
>> operations such as saving buffers to file.  In Eldoc, we even
>> explicitly tell users to add functions to the local part of this
>> abnormal hook (eldoc-documentation-functions), thereby telling them to
>> rely on "undefined" behavior!  This hopefully shows that the behavior
>> is far from being undefined.
> 
> I don't think it shows any such thing.

Why not?  Clearly there are hooks that are both abnormal and partially-local in the Emacs codebase, and for those hooks this issue arises.

> 
> I think it'd be a good idea to implement (and document) something in
> this area that actually allows users to control the hook running order
> properly, which currently just isn't possible.
> 

Yes, and arguably the current implementation with the "shadow" ordering stored in a private symbol property is already kind of a hack.  However, the second-best option is still to document the current behavior.  As I've tried to explain, just stating "it's undefined" won't fly.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.