Hmm, I see the problem. I didn't think about that. Thank you very much for your suggestion. But what about using read-char-exclusive? It seems to have a timeout argument too, and should apparently fix the issue (ie. the prompt will no longer disappear at the first unintentional click).
Romeo Ignacio Casso <ignacioca...@hotmail.com> writes: >> Hi, >> >> I don't know how closely it is related to your problem, but I've >> reported another issue revolving around the use of read-char for the >> prompt to resolve clocks. See >> [[https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html]]. >> >> Unfortunately I an not advanced enough in Elisp to know whether using >> another function than read-char would solve your problem as well as >> mine (maybe read-char-choice waits for a valid char, while resetting >> the idle timer ?), but it might be a hint. What do you think ? > > The problem with `read-char-choice' is that it does not seem to have a > timeout argument. `read-char' has, and `org-clock-resolve' uses it to > update the prompt message with the current idle time every 45 seconds, > calling (read-char ... 45) in a loop until it returns non-nil. With > `read-char-choice' that would not be possible, and if > `org-clock-idle-time' was N, after the N idle minutes, the prompt would > appear saying something like "Emacs was idle for N minutes, what do you > want to do?", but M minutes later the message would still be the same > instead of replacing N with N+M. > > The patch I sent already fixes the bug I reported anyway. For yours, I > suggest just wrapping `read-char' in `condition-case', unless someone > knows of some other appropriate function.
