GNU bug report logs - #61176
post-command-hook is not run if minibuffer input is aborted

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 61176 <at> debbugs.gnu.org
Subject: Re: bug#61176: post-command-hook is not run if minibuffer input is
 aborted
Date: Sun, 05 Feb 2023 09:47:42 -0500

> And if the user DOES abort, I would like the behavior to be changed like
> so:
>
>>> ;; -setup   ([f1]       -command)
>>> ;; -post    ([]         -command)
>>> ;; -exit    ([7]        abort-minibuffers)
>>> ;; Quit
>>> ;; -post    ([]         abort-minibuffers)
> *NEW* -post    ([f1]       -command)

Hmm... fully agreed and I wonder why it's not run.
[ The rest of the discussion is largely independent from this.  ]

> The suffix command may use the minibuffer inside interactive and/or in
> its body.  If that happens, then transient has to suspend the transient
> keymap and pre- and post-command functions, while the minibuffer is in
> use.

FWIW, I have played with similar issues in the context of prefix
commands and `set-transient-map` (yet, can't find the corresponding
code, sorry) and I remember using `minibuffer-depth` to detect the use
of a minibuffer (i.e. record the original `minibuffer-depth` and/or
`recursion-depth` compare it to the current depth in
`pre-command-hook`).
I see `transient.el` also uses `minibuffer-depth`, so I guess I'm not
telling you anything you didn't already know.

I also remember considering adding hooks to `read-from-minibuffer` and
`recursive-edit` so we can more proactively and reliably let-bind
variables around them (e.g. we should let-bind `this-command` around
them).


        Stefan

Previous Next

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