On Mon, 4 Jul 2022 at 17:32, Ihor Radchenko <yanta...@gmail.com> wrote: > > While looking at the *Messages* buffer, I came across the command > > y-or-n-p-insert-y. There are commands for n, and other keys. When we > > press y, M-p etc, these commands get executed. So, even if we manage to > > fix the initial example in Emacs, the hook will still run while one is > > in the minibuffer. > > This explains the observed behavior.
Apart from these commands triggering the post-command-hook, there is one additional time it gets executed. This is the place when y-or-n-p calls read-from-minibuffer. When read-from-minibuffer executes, this-command remains my-test-command. > A possible fix could be let-binding post-command-hook to > (delq #'org-add-log-note post-command-hook), though we may get a similar > issue in other context in future. > > A better fix may relate to the fact that org-add-log-setup is usually > used to run org-add-log-note at the end of current command. y-or-n-p or > any other kind of command (e.g. added via advice) will break this > assumption we use. So, org-add-log-setup could also store > `this-command', say, in `org-log-note-this-command' and > `org-add-log-note' can then execute only when `this-command' is the same > with `org-log-note-this-command'. WDYT? I had something similar in my mind, something like we check if this-command is org-* (not very robust). Your idea makes sense to me. But this won't work when read-from-minibuffer is called as it doesn't seem to change this-command when it runs. I had created an Emacs bug report: https://debbugs.gnu.org/56425 -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
