GNU bug report logs - #56425
28.1; post-command-hook is triggered on y-or-n-p

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56425 in the body.
You can then email your comments to 56425 AT debbugs.gnu.org in the normal way.

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

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

From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; post-command-hook is triggered on y-or-n-p
Date: Wed, 6 Jul 2022 23:25:34 +0530

Run emacs -Q and evaluate following code:

(defvar my-hook-counter)
(defun my-test-command ()
  (interactive)
  (message "my-test-command: setting post-command-hook")
  (setq my-hook-counter 3)
  (add-hook 'post-command-hook 'my-own-hook)
  (y-or-n-p "Some question: ")
  (message "my-test-command: message after setting the hook")
)
(defun my-own-hook ()
  (print (format "hook: this: %s, real: %s, last: %s" this-command
real-this-command last-command))
  (message "my-own-hook: hopefully executing at the end")
  (setq my-hook-counter (- my-hook-counter 1))
  (if (eq my-hook-counter 0)
      (remove-hook 'post-command-hook 'my-own-hook))
)

1. M-x my-test-command
2. Emacs is now waiting for the input in the minibuffer. And also the
   post-command-hook executes here.
   minibuffer] Some question: (y or n)  [my-own-hook: hopefully
executing at the end]
3. Answer y in the minibuffer.
   minibuffer] my-test-command: message after setting the hook

In the *Messages* buffer the sequence is:

--8<---------------cut here---------------start------------->8---
my-test-command: setting post-command-hook

"hook: this: my-test-command, real: my-test-command, last: keyboard-quit"

my-own-hook: hopefully executing at the end
^^^^^ unexpected execution of post-command-hook for my-test-command

Some question: (y or n) y
my-test-command: message after setting the hook

"hook: this: my-test-command, real: y-or-n-p-insert-y, last: my-test-command"

my-own-hook: hopefully executing at the end
--8<---------------cut here---------------end--------------->8---


When I run M-x my-test-command, the post-command-hook is executed while
Emacs is waiting for the user input (y-or-n-p) in the
minibuffer. And we get this in *Messages* buffer:

"hook: this: my-test-command, real: my-test-command, last: keyboard-quit"

My initial thought was that the y-or-n-p call is causing it.  Looking at
the code of y-or-n-p with my limited Elisp knowledge, it doesn't seems
to be an interactive function, and there aren't any calls to interactive
functions till it prints the message "Some question: " in
minibuffer. And, from the print statement this-command is
my-test-command and not y-or-n-p.

Also, my-test-command has not finished executing yet, it is waiting for
user input, so how does it trigger the post-command-hook?  I'm not able
to understand what causes it to trigger the post-command-hook, is it an
expected behavior? I'm I missing something here? Is read-from-minibuffer
triggering the post-command-hook?


In GNU Emacs 28.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.31, cairo version 1.17.6)
 of 2022-05-12 built on 798eb2d274a4426aa2879373741c952d
Windowing system distributor 'The X.Org Foundation', version 11.0.12201002
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json --with-native-compilation
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects
 -fexceptions -g -grecord-gcc-switches -pipe -Wall
 -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr ispell dabbrev emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map text-property-search
time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 73671 7615)
 (symbols 48 6866 0)
 (strings 32 20919 2083)
 (string-bytes 1 717484)
 (vectors 16 14470)
 (vector-slots 8 304968 20189)
 (floats 8 34 64)
 (intervals 56 371 0)
 (buffers 992 12))
-- 
Bhavin Gandhi (bhavin192) | https://geeksocket.in

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

From: Juri Linkov <juri <at> linkov.net>
To: Bhavin Gandhi <bhavin7392 <at> gmail.com>
Cc: 56425 <at> debbugs.gnu.org
Subject: Re: bug#56425: 28.1; post-command-hook is triggered on y-or-n-p
Date: Wed, 06 Jul 2022 21:19:00 +0300

> Is read-from-minibuffer triggering the post-command-hook?

This is the most interesting question.  When you replace the y-or-n-p call
in your code with read-from-minibuffer, do you see the same result?

If not, then maybe these lines y-or-n-p affect the behavior somehow,
but I'm sure:

  ;; Protect this-command when called from pre-command-hook (bug#45029)
  (this-command this-command)

If all fails, then as the last resort you always have an option to
fall back to the modal behavior of y-or-n-p by wrapping the call
with y-or-n-p-use-read-key:

  (let ((y-or-n-p-use-read-key t)) (y-or-n-p "Some question: "))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bhavin Gandhi <bhavin7392 <at> gmail.com>
Cc: 56425 <at> debbugs.gnu.org
Subject: Re: bug#56425: 28.1; post-command-hook is triggered on y-or-n-p
Date: Wed, 06 Jul 2022 22:03:45 +0300

> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Wed, 6 Jul 2022 23:25:34 +0530
> 
> Also, my-test-command has not finished executing yet, it is waiting for
> user input, so how does it trigger the post-command-hook?  I'm not able
> to understand what causes it to trigger the post-command-hook, is it an
> expected behavior?

Yes.

> I'm I missing something here? Is read-from-minibuffer
> triggering the post-command-hook?

Yes.

Why are you surprised?  y-or-n-p invokes read-from-minibuffer, which
invokes recursive-edit, which starts a recursive command loop.  And
the command loop calls post-command-hook on each iteration.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Bhavin Gandhi <bhavin7392 <at> gmail.com>, 56425 <at> debbugs.gnu.org
Subject: Re: bug#56425: 28.1; post-command-hook is triggered on y-or-n-p
Date: Mon, 11 Jul 2022 12:54:26 +0200

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

> Why are you surprised?  y-or-n-p invokes read-from-minibuffer, which
> invokes recursive-edit, which starts a recursive command loop.  And
> the command loop calls post-command-hook on each iteration.

When writing post-command-hook code, you have to be check whether you're
in the context you want to be (for instance, in the minubuffer or not).
I think it's always been this way, but these day we use the
read-from-minibuffer a lot more than we used to -- so y-or-n-p didn't
use to have this issue, but it does now.

But I think things are working as designed here, basically, so I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: bhavin7392 <at> gmail.com, 56425 <at> debbugs.gnu.org
Subject: Re: bug#56425: 28.1; post-command-hook is triggered on y-or-n-p
Date: Mon, 11 Jul 2022 14:39:31 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Bhavin Gandhi <bhavin7392 <at> gmail.com>,  56425 <at> debbugs.gnu.org
> Date: Mon, 11 Jul 2022 12:54:26 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why are you surprised?  y-or-n-p invokes read-from-minibuffer, which
> > invokes recursive-edit, which starts a recursive command loop.  And
> > the command loop calls post-command-hook on each iteration.
> 
> When writing post-command-hook code, you have to be check whether you're
> in the context you want to be (for instance, in the minubuffer or not).
> I think it's always been this way, but these day we use the
> read-from-minibuffer a lot more than we used to -- so y-or-n-p didn't
> use to have this issue, but it does now.

Yes.  Code that wants to distinguish these cases from "normal"
post-command-hook invocations should examine the value of
minibuffer-depth, I think.

Previous Next

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