emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Roméo La Spina" <romeo.laspina1@gmail.com>
To: Ignacio Casso <ignaciocasso@hotmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Date: Sat, 19 Mar 2022 11:07:38 +0100	[thread overview]
Message-ID: <878rt6cjsa.fsf@gmail.com> (raw)
In-Reply-To: <PAXPR06MB77606EE21997660E56125AA6C60E9@PAXPR06MB7760.eurprd06.prod.outlook.com>


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 ?


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

  reply	other threads:[~2022-03-19 10:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87sfrnqlbu.fsf@hotmail.com>
2022-03-13 20:42 ` Ignacio Casso
2022-03-19 10:07   ` Roméo La Spina [this message]
2022-03-19 11:08     ` Ignacio Casso
2022-03-19 12:29       ` Roméo La Spina
2022-03-20 12:21         ` Ignacio Casso
2022-03-20 21:02           ` Roméo La Spina
2022-03-12 11:07 Ignacio Casso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rt6cjsa.fsf@gmail.com \
    --to=romeo.laspina1@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ignaciocasso@hotmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).