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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 78180 <at> debbugs.gnu.org
Subject: 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)?

Previous Next

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