Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]


> 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-emacs@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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch for org-resolve-clocks-if-idle bug --]
[-- Type: text/x-diff, Size: 1441 bytes --]

From 288b25ea95699596762b199088ce6828a5e9a0ed Mon Sep 17 00:00:00 2001
From: Ignacio <ignacio.decasso@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
-- 
2.25.1

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Roméo La Spina]

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 <ignaciocasso@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-emacs@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.decasso@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

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

> 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.

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Roméo La Spina]

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 <ignaciocasso@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.

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

> 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
>

That would indeed fix your bug, it seems. Not mine, since it
does not reset the idle timer either. I suggest you reply
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html
with a patch, just replacing `read-char' with `read-char-exclusive'.

--Ignacio

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Roméo La Spina]

Thanks for your answer! I will do that as soon as I have a little more time.

Ignacio Casso <ignaciocasso@hotmail.com> writes:

>> 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
>>
>
> That would indeed fix your bug, it seems. Not mine, since it
> does not reset the idle timer either. I suggest you reply
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html
> with a patch, just replacing `read-char' with `read-char-exclusive'.
>
> --Ignacio

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ihor Radchenko]

Ignacio Casso <ignaciocasso@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-emacs@gnu.org, but it seems there is a reason for that. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54371

Fixed on main by merging your other patch.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=31f2510995c938d96947086ecd807d9b148ec7f8

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

[BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

Hello,

> CONTEXT:  When I'm idling with the clock running, Org asks if I want
> to resolve the clock when I come back (this is by setting
> org-clock-idle-time).
> 
> PROBLEM: I'm not sure how recent the change was, but Org started
> asking me _multiple times_ what I want to do when back.

I have this problem, already reported but not solved in these threads
and maybe others:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00333.html,
https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00188.html.

I have investigated a little and it seems that there is a timer that
calls org-resolve-clocks-if-idle every minute, and if
(org-user-idle-seconds) is greater than 60*org-clock-idle-time, that
function prompts the user to resolve the clock. The problem is that this
prompt blocks Emacs, and if you are idle (org-clock-idle-time + N)
minutes, the other N scheduled calls to org-resolve-clocks-if-idle occur
immediately after answering the prompt. But for some reason (a bug?),
answering the prompt does not affect (org-user-idle-seconds), so the
prompt appears again, and you have to answer it N times (unless your
answer was to cancel the clock or clock out).

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.

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. 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.

What do yo think?



Emacs  : GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2022-03-11
Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)