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 ? Regards, Romeo Ignacio Casso <ignacioca...@hotmail.com> writes: >> So the problem is in (org-user-idle-seconds), which in my window system >> boils down to a call to (current-idle-time). It should return 0 after >> answering the prompt, but in my system it keeps counting up. At this >> point I stopped investigating since that function is defined in C. >> > > I have investigated this a little bit further and it seems that reading > a character with read-char only resets the idle timer if the SECONDS > argument is nil (which is not the case here) . I reported it as a bug to > bug-gnu-em...@gnu.org, but it seems there is a reason for that. See > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54371 > >> Since this bug is already old and I have not found much information >> about it, I assume that in most systems answering the prompt does reset >> the idle timer and this bug does not occur. > > It also seems to happen for all systems, so either much less people than > I thought use this feature, or there is something else that makes this > bug particular to my setup, although I can't think of anything else. > >> As a quick fix for those >> systems where this is an issue, we could reset the idle timer ourselves >> after the prompt in org-resolve-clocks-if-idle. > > I have thought of a better way to fix this, and currently there is no > way to do reset the idle timer with Elisp anyway. I attach the patch: it > just cancels the timer before prompting the user and sets it again if > needed after the prompt is answered. What do you think? > > [2. Patch for org-resolve-clocks-if-idle bug --- text/x-diff; > 0001-fixed-bug.patch] > From 288b25ea95699596762b199088ce6828a5e9a0ed Mon Sep 17 00:00:00 2001 > From: Ignacio <ignacio.deca...@imdea.org> > Date: Sun, 13 Mar 2022 21:41:43 +0100 > Subject: [PATCH] fixed bug > > --- > lisp/org/org-clock.el | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el > index dce5d9d4c0..81d4a85782 100644 > --- a/lisp/org/org-clock.el > +++ b/lisp/org/org-clock.el > @@ -1228,7 +1228,9 @@ org-resolve-clocks-if-idle > (org-clock-user-idle-start > (org-time-since org-clock-user-idle-seconds)) > (org-clock-resolving-clocks-due-to-idleness t)) > - (if (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) > + (when (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) > + (cancel-timer org-clock-idle-timer) > + (setq org-clock-idle-timer nil) > (org-clock-resolve > (cons org-clock-marker > org-clock-start-time) > @@ -1237,7 +1239,10 @@ org-resolve-clocks-if-idle > (/ (float-time > (time-since org-clock-user-idle-start)) > 60))) > - org-clock-user-idle-start))))) > + org-clock-user-idle-start) > + (when (and (org-clocking-p) (not org-clock-idle-timer)) > + (setq org-clock-idle-timer > + (run-with-timer 60 60 #'org-resolve-clocks-if-idle))))))) > > (defvar org-clock-current-task nil "Task currently clocked in.") > (defvar org-clock-out-time nil) ; store the time of the last clock-out
