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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Thu, 1 May 2025 08:46:01 UTC

Severity: normal

Found in version 31.0.50

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

Bug is archived. No further changes may be made.

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 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.




This bug report was last modified 59 days ago.

Previous Next


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