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

Previous Next

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