bug-gnu-emacs
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]