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

[Eli Zaretskii]

> From: Ignacio Casso <ignaciocasso@hotmail.com>
> Date: Sun, 13 Mar 2022 00:27:59 +0100
> 
> If I evaluate the following snippet, after 3 seconds Emacs prompts me
> for a character and prints nil.
> 
>   (defun my-test ()
>     (read-char "> " nil nil)
>     (message "%s" (current-idle-time)))
> 
>   (run-with-timer 3 nil 'my-test)
> 
> However, if I evaluate the following snippet instead, where the last
> argument of read-char is changed to the number of seconds the prompt
> should wait at most for user input, it prints (0 K _ _), where K is 3
> seconds plus whatever time in seconds you took to answer the
> prompt. This means that right after reading a character from user input
> Emacs still thinks it has been idle for a while.
> 
>   (defun my-test ()
>     (read-char "> " nil 10)
>     (message "%s" (current-idle-time)))
> 
>   (run-with-timer 3 nil 'my-test)
> 
> This is the reason behind a bug that occurs when resolving the running
> org clock after some idle time, for which I have seen reports more than
> 10 years old but not as much discussion as I would expect. This makes me
> think that Emacs does not behave like this for most systems and the
> problem is particular to my setup. My setup should not be particular in
> any sense however, just an Ubuntu 20.04 with default and standard
> packages. Emacs' is the only configuration I have ever tweaked in my
> machine, and this happens also with "emacs -Q", so it's not that.
> 
> Can you please evaluate the second snippet to try to reproduce this in
> your machine?

I can reproduce this.

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.