GNU bug report logs - #78180
31.0.50; Since ab71699e5f2, global value of post-command-hook is useless

Previous Next

To reply to this bug, email your comments to 78180 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Since ab71699e5f2, global value of post-command-hook is
 useless
Date: Thu, 01 May 2025 08:44:01 +0000

Hi,

Before commit ab71699e5f2, global-eldoc-mode (enabled by default) did
nothing in most buffers and only activated when a given major mode
defined `eldoc-documentation-functions' (so that `eldoc--supported-p'
returns non-nil).

One can easily see this via
1. emacs -Q
2. C-x b *Messages* RET
3. M-: post-command-hook (nil)

After ab71699e5f2, `eldoc-documentation-functions' is no longer nil by
default, with immediate effect of *every single buffer* having
eldoc-mode enabled.

Enabling eldoc-mode itself is not a big deal. What is a big deal is the
fact that it is no longer possible to setup post-command-hook globally,
not just in current buffer, but also in all the future new buffers.
It is also not possible to setup transient hooks (self-removed upon
first execution) as long as current command ends up in different buffer.

(It was technically not exactly possible in the past as well, for
buffers holding their buffer-local post-command-hook value, but the
problem was less obvious as most buffers had post-command-hook set to
its default value)

The problem may affect:
1. Org mode (that's how I found the problem)
2. vcursor.el, vc.el, type-break.el, transient.el, xterm.el,
   scroll-all.el, global-reveal-mode, repeat-mode, gud.el, flymake,
   elisp-mode.el, and basically any other part of Emacs setting global
   default value of post-command-hook.

I do no think that ab71699e5f2 itself is doing anything wrong, but
rather that the design of post-command-hook is not ideal for its
purpose. The fact that we were able to get along with the current design
is by pure chance and the fact that most buffers did not set
buffer-local value of post-command-hook.

Maybe we should introduce post-command-global-hook that will be
evaluated in every single buffer and leave post-command-hook to be used
locally (maybe even rename it to post-command-local-hook for
clarity). Maybe similar for pre-command-hook.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-04-29 built on localhost
Repository revision: 3a514005d153df429b0ed58ac64300296b9d5aac
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Gentoo Linux
-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 78180 <at> debbugs.gnu.org
Subject: Re: bug#78180: 31.0.50;
 Since ab71699e5f2, global value of post-command-hook is useless
Date: Thu, 01 May 2025 20:07:57 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Date: Thu, 01 May 2025 08:44:01 +0000
> 
> Before commit ab71699e5f2, global-eldoc-mode (enabled by default) did
> nothing in most buffers and only activated when a given major mode
> defined `eldoc-documentation-functions' (so that `eldoc--supported-p'
> returns non-nil).
> 
> One can easily see this via
> 1. emacs -Q
> 2. C-x b *Messages* RET
> 3. M-: post-command-hook (nil)
> 
> After ab71699e5f2, `eldoc-documentation-functions' is no longer nil by
> default, with immediate effect of *every single buffer* having
> eldoc-mode enabled.
> 
> Enabling eldoc-mode itself is not a big deal. What is a big deal is the
> fact that it is no longer possible to setup post-command-hook globally,
> not just in current buffer, but also in all the future new buffers.

Please explain why "it is no longer possible to setup
post-command-hook globally", or what do you mean by "impossible".
Your claim that the global value of post-command-hook is now useless
sounds grave, but you never explain why you make such a claim.

The post-command-hook is modified by calling add-hook and remove-hook,
which still work.  The global value of post-command-hook was non-nil
by default before the above change, and it is still not nil after it.
Please explain why you consider that change to have such a grave
effect.  Yes, it does mean most buffers will see a non-nil value of
post-command-hook; no, it is completely unclear why is that a bad
thing, nor even why you think it's a significant change, since there's
another hook in the default value besides eldoc-mode's one, which was
there before the change.

> It is also not possible to setup transient hooks (self-removed upon
> first execution) as long as current command ends up in different buffer.

Why not?  Again, please tell the details.

> (It was technically not exactly possible in the past as well, for
> buffers holding their buffer-local post-command-hook value, but the
> problem was less obvious as most buffers had post-command-hook set to
> its default value)

AFAIU, it is still the case that most buffers have post-command-hook
set to its default value.  If not, please explain why not.

> The problem may affect:
> 1. Org mode (that's how I found the problem)
> 2. vcursor.el, vc.el, type-break.el, transient.el, xterm.el,
>    scroll-all.el, global-reveal-mode, repeat-mode, gud.el, flymake,
>    elisp-mode.el, and basically any other part of Emacs setting global
>    default value of post-command-hook.

Affect how?  Please explain that, not just claim it.

> I do no think that ab71699e5f2 itself is doing anything wrong, but
> rather that the design of post-command-hook is not ideal for its
> purpose. The fact that we were able to get along with the current design
> is by pure chance and the fact that most buffers did not set
> buffer-local value of post-command-hook.

This again lacks critical details.  Please fill in the blanks.

Thanks.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78180 <at> debbugs.gnu.org
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Thu, 01 May 2025 17:51:37 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> Please explain why "it is no longer possible to setup
> post-command-hook globally", or what do you mean by "impossible".
> Your claim that the global value of post-command-hook is now useless
> sounds grave, but you never explain why you make such a claim.

By "impossible", I did not mean that you cannot set global value, but
rather that pretty much every single buffer will have a buffer-local
value that is shadowing the global value set by add-hook without LOCAL
arg.

Although, I now tested things more rigorously, and post-command-hook
does get evaluated, despite the above. So, I clearly miss something
about how and in which context post-command-hook is evaluated.

> The post-command-hook is modified by calling add-hook and remove-hook,
> which still work.  The global value of post-command-hook was non-nil
> by default before the above change, and it is still not nil after it.

You are right that the global value does get set and it is non-nil.
The problem is with buffer-local value - with eldoc-mode, which is,
after ab71699e5f2, enabled by default in all buffers, every single new
buffer will have non-nil buffer-local value of post-command-hook.

>> It is also not possible to setup transient hooks (self-removed upon
>> first execution) as long as current command ends up in different buffer.
>
> Why not?  Again, please tell the details.

>> (It was technically not exactly possible in the past as well, for
>> buffers holding their buffer-local post-command-hook value, but the
>> problem was less obvious as most buffers had post-command-hook set to
>> its default value)
>
> AFAIU, it is still the case that most buffers have post-command-hook
> set to its default value.  If not, please explain why not.

This is not true - most buffers, after ab71699e5f2, do _not_ have
post-command-hook set to its default value. Let me provide an illustration:

1. emacs -Q
2. M-: (add-hook 'post-command-hook #'always)
2. M-: (dolist (buf (buffer-list))
     (with-current-buffer buf
       (message "%S -> %S" buf post-command-hook)))
3. Observe the following in *Messages*

#<buffer *scratch*> -> (jit-lock--antiblink-post-command eldoc-schedule-timer t)
#<buffer  *Minibuf-1*> -> (eldoc-schedule-timer t)
#<buffer  *Minibuf-0*> -> (eldoc-schedule-timer t)
#<buffer *Messages*> -> (eldoc-schedule-timer t)
#<buffer  *Echo Area 0*> -> (always)
#<buffer  *Echo Area 1*> -> (always)

4. Create a new buffer C-x b new RET
5. M-: post-command-hook RET
   
   (eldoc-schedule-timer t)   

   The new buffers gets buffer-local value, not global (always) value.

I note that Echo Area still gets the global hook value. Maybe it can
explain why global value of post-command-hook still gets executed in my
interactive testing.

I did the following test, I left wondering what is going on:

1. emacs -Q
2. (trace-function #'always)
3. (trace-function #'eldoc-schedule-timer)
4. (add-hook 'post-command-hook #'always)
5. C-n C-p C-n C-p
6. Observe _both_ buffer-local and global values of post-command-hook
   executed. Why is that?

>> The problem may affect:
>> 1. Org mode (that's how I found the problem)
>> 2. vcursor.el, vc.el, type-break.el, transient.el, xterm.el,
>>    scroll-all.el, global-reveal-mode, repeat-mode, gud.el, flymake,
>>    elisp-mode.el, and basically any other part of Emacs setting global
>>    default value of post-command-hook.
>
> Affect how?  Please explain that, not just claim it.

That claim was based on my incomplete understanding. You can ignore this
part.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 78180 <at> debbugs.gnu.org
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Thu, 01 May 2025 21:09:50 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: 78180 <at> debbugs.gnu.org
> Date: Thu, 01 May 2025 17:51:37 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Please explain why "it is no longer possible to setup
> > post-command-hook globally", or what do you mean by "impossible".
> > Your claim that the global value of post-command-hook is now useless
> > sounds grave, but you never explain why you make such a claim.
> 
> By "impossible", I did not mean that you cannot set global value, but
> rather that pretty much every single buffer will have a buffer-local
> value that is shadowing the global value set by add-hook without LOCAL
> arg.

But only for the eldoc hook, right?  Because if not, I still don't
understand what you are saying.

> Although, I now tested things more rigorously, and post-command-hook
> does get evaluated, despite the above. So, I clearly miss something
> about how and in which context post-command-hook is evaluated.

May I suggest that you first describe the actual problem you bumped
into?

> > The post-command-hook is modified by calling add-hook and remove-hook,
> > which still work.  The global value of post-command-hook was non-nil
> > by default before the above change, and it is still not nil after it.
> 
> You are right that the global value does get set and it is non-nil.
> The problem is with buffer-local value - with eldoc-mode, which is,
> after ab71699e5f2, enabled by default in all buffers, every single new
> buffer will have non-nil buffer-local value of post-command-hook.

And that is bad because..?

> >> It is also not possible to setup transient hooks (self-removed upon
> >> first execution) as long as current command ends up in different buffer.
> >
> > Why not?  Again, please tell the details.
> 
> >> (It was technically not exactly possible in the past as well, for
> >> buffers holding their buffer-local post-command-hook value, but the
> >> problem was less obvious as most buffers had post-command-hook set to
> >> its default value)
> >
> > AFAIU, it is still the case that most buffers have post-command-hook
> > set to its default value.  If not, please explain why not.
> 
> This is not true - most buffers, after ab71699e5f2, do _not_ have
> post-command-hook set to its default value. Let me provide an illustration:
> 
> 1. emacs -Q
> 2. M-: (add-hook 'post-command-hook #'always)
> 2. M-: (dolist (buf (buffer-list))
>      (with-current-buffer buf
>        (message "%S -> %S" buf post-command-hook)))
> 3. Observe the following in *Messages*
> 
> #<buffer *scratch*> -> (jit-lock--antiblink-post-command eldoc-schedule-timer t)
> #<buffer  *Minibuf-1*> -> (eldoc-schedule-timer t)
> #<buffer  *Minibuf-0*> -> (eldoc-schedule-timer t)
> #<buffer *Messages*> -> (eldoc-schedule-timer t)
> #<buffer  *Echo Area 0*> -> (always)
> #<buffer  *Echo Area 1*> -> (always)
> 
> 4. Create a new buffer C-x b new RET
> 5. M-: post-command-hook RET
>    
>    (eldoc-schedule-timer t)   

So the problem is that buffer-local hooks now have
eldoc-schedule-timer added?  Is that the only problem?  And if so, why
is it a problem?  Surely, there are gazillion of use cases in Emacs
where many buffers have buffer-local post-command-hook different from
the global value; why is it a problem in this case (or in all those
cases)?

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78180 <at> debbugs.gnu.org
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Thu, 01 May 2025 18:23:49 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> rather that pretty much every single buffer will have a buffer-local
>> value that is shadowing the global value set by add-hook without LOCAL
>> arg.
>
> But only for the eldoc hook, right?  Because if not, I still don't
> understand what you are saying.

Sorry, but I do not understand your question.

>> Although, I now tested things more rigorously, and post-command-hook
>> does get evaluated, despite the above. So, I clearly miss something
>> about how and in which context post-command-hook is evaluated.
>
> May I suggest that you first describe the actual problem you bumped
> into?

The problem is rather simple - some of Org's tests make an assumption
that the value of `post-command-hook' is its global value in Org
buffers. It is no longer the case after ab71699e5f2.

When I was investigating the test failures, I thought that the problem
might be much more far-reaching than a simple test breaking. That's why
this bug report, and not the trivial fix of the tests.

>> 4. Create a new buffer C-x b new RET
>> 5. M-: post-command-hook RET
>>    
>>    (eldoc-schedule-timer t)   
>
> So the problem is that buffer-local hooks now have
> eldoc-schedule-timer added?  Is that the only problem?  And if so, why
> is it a problem?  Surely, there are gazillion of use cases in Emacs
> where many buffers have buffer-local post-command-hook different from
> the global value; why is it a problem in this case (or in all those
> cases)?

Well. First, I thought that it is a problem because presence of
buffer-local value preventing globally added hooks to be executed. It is
not a problem (for some reason I don't fully understand).

What else _might_ be a problem (but I am a bit lost in how things work
here) is direct invocations of (run-hooks 'post-command-hook) from
Elisp: in ert-x.el, gnus-msg.el, org-mouse.el. AFAIU, such calls will
only execute buffer-local post-comman-hook, not global. Maybe I miss
something.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 78180 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Fri, 02 May 2025 04:23:01 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> What else _might_ be a problem (but I am a bit lost in how things work
> here) is direct invocations of (run-hooks 'post-command-hook) from
> Elisp: in ert-x.el, gnus-msg.el, org-mouse.el. AFAIU, such calls will
> only execute buffer-local post-comman-hook, not global. Maybe I miss
> something.

Just to be sure: you are aware that in the normal case the global hook
binding will always be executed (additionally), as long as the symbol t
is not removed from the local hook binding, as explained in
(info "(elisp) Setting Hooks")?


Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78180 <at> debbugs.gnu.org
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Fri, 02 May 2025 09:04:22 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: 78180 <at> debbugs.gnu.org
> Date: Thu, 01 May 2025 18:23:49 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > May I suggest that you first describe the actual problem you bumped
> > into?
> 
> The problem is rather simple - some of Org's tests make an assumption
> that the value of `post-command-hook' is its global value in Org
> buffers. It is no longer the case after ab71699e5f2.

Isn't that a wrong assumption?  A global minor mode can legitimately
invalidate it, right?

Stefan, am I missing something here?

> What else _might_ be a problem (but I am a bit lost in how things work
> here) is direct invocations of (run-hooks 'post-command-hook) from
> Elisp: in ert-x.el, gnus-msg.el, org-mouse.el. AFAIU, such calls will
> only execute buffer-local post-comman-hook, not global. Maybe I miss
> something.

See Michael's response, I think he answered this.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 78180 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Fri, 02 May 2025 06:54:08 +0000

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Just to be sure: you are aware that in the normal case the global hook
> binding will always be executed (additionally), as long as the symbol t
> is not removed from the local hook binding, as explained in
> (info "(elisp) Setting Hooks")?

I was not aware! That's embarrassing.

Now, I see

     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 ‘t’, the global hook
     variable will be run as well.

IMHO, that detail might look good in 24.1 Hooks section itself, as it
appears to be important. But maybe it is just me who did not notice
this.

In any case, there is no bug in what I reported. Just my
misunderstanding. Feel free to close.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78180 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>
Subject: Re: bug#78180: 31.0.50; Since ab71699e5f2, global value of
 post-command-hook is useless
Date: Fri, 02 May 2025 11:33:10 -0400

>> The problem is rather simple - some of Org's tests make an assumption
>> that the value of `post-command-hook' is its global value in Org
>> buffers. It is no longer the case after ab71699e5f2.
> Isn't that a wrong assumption?  A global minor mode can legitimately
> invalidate it, right?

+1


        Stefan

Previous Next

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