Bhavin Gandhi <bhavin7...@gmail.com> writes:
>> Thanks for the idea, I'm exploring (recursion-depth),
>> (minibuffer-depth). I will come up with a patch to fix this bug.
>
> So, I saved this-command and (recursion-depth) value, and I'm checking
> for it in the org-add-log-note (attaching diff of my changes). But this
> doesn't guarantee that we are not in the minibuffer when the
> post-command-hook runs.
>
> This is what I did, and it failed after answering the question about 10
> repeated intervals:
> 1. M-: (y-or-n-p "Some question")
> 2. Now I switched to Org mode buffer.
> 3. Did C-c C-t on the entry.
>
> When org-log-add-setup runs, (recursion-depth) is 1, and
> (minibuffer-depth) is also 1.
> Now, the question about 10 repeated intervals is asked, once I answer
> it, post-command-hook runs. And it runs while we are in the minibuffer
> waiting for 'Some question'.
Yikes! Then, can also check for window-minibuffer-p, but I feel that it
will be a fight against all kinds of edge cases.
> So, I changed the second condition to (= (minibuffer-depth) 0).
> This has a different effect when org-todo finishes the execution and we
> are still in minibuffer:
> this-command won't be org-todo again unless it is invoked again by the
> user. org-add-log-note post-command-hook is never removed, and it keeps
> executing as the condition is not fulfilled.
>
> I'm going through the code of org-add-log-note to see if we can avoid
> calling (delete-other-windows) in the minibuffer. Or move out of minibuffer
> and then proceed.
what about
(when (or (and (equal org-log-note-this-command this-command)
(= org-log-note-recursion-depth (recursion-depth)))
(> org-log-note-recursion-depth (recursion-depth)))
Best,
Ihor
