[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61176: post-command-hook is not run if minibuffer input is aborted
From: |
Stefan Monnier |
Subject: |
bug#61176: post-command-hook is not run if minibuffer input is aborted |
Date: |
Sun, 05 Feb 2023 09:47:42 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> 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