Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note

[Bhavin Gandhi <bhavin7392@gmail.com>]

On Mon, 4 Jul 2022 at 17:32, Ihor Radchenko <yantar92@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