bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54371: 29.0.50; read-char does not reset idle timer in some cases


From: Ignacio Casso
Subject: bug#54371: 29.0.50; read-char does not reset idle timer in some cases
Date: Sun, 13 Mar 2022 18:45:33 +0100
User-agent: mu4e 1.6.10; emacs 27.2

> I think we should first understand the use case better.  For starters,
> I don't think I understand why an idle timer function should want to
> call read-char with a time-out.  It is a strange thing to do, IMO.

The function in question is org-resolve-clocks-if-idle. It runs with a
normal timer (not idle) every 60 seconds, and resolves the running org
clock if (current-idle-time) is greater than the time specified by the
variable org-clock-idle-time. To do so, it prompts the user for a
character that indicates which action to take, with a prompt text that
indicates the current idle time: "Clocked in & idle for X mins
[jkKtTgGSscCiq]? ". To provide a relatively up-to-date current idle time
in the prompt text, it reads the char with a timeout in the following
loop:

  (while (or (null char-pressed)
             (and (not (memq char-pressed
                             '(?k ?K ?g ?G ?s ?S ?C
                                  ?j ?J ?i ?q ?t ?T)))
                  (or (ding) t)))
    (setq char-pressed
          (read-char (concat (funcall prompt-fn clock)
                             " [jkKtTgGSscCiq]? ")
                     nil 45)))


Since the idle time is not reset after the character is read, this
produces the bug I explained in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00127.html,
but otherwise I find it to be reasonable code.

> Doesn't seem to be anything reachable from Lisp land.  Adding a subr
> that just calls timer_start_idle would be trivial, though.

I think that particular bug with org-clock can be fixed with other
workarounds that do not involve resetting the idle timer. No need to
expose that code only for that if it isn't already exposed.

> However, it sounds like we do this on purpose, to avoid problems with
> idle timers that call sit-for.  See the discussion that started here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00395.html
>
> The change installed at that time made read_char avoid restarting idle
> timers when it is called with a non-nil END_TIME argument.

However, I still think that if not a bug, this is at least inconsistent
and probably deserving a footnote in the relevant section of the Emacs
Lisp manual
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Idle-Timers.html).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]