Re: sit-for and idle timers

[Chong Yidong <cyd@stupidchicken.com>]

Noah Friedman <friedman@splode.com> writes:

> The less simple solution is probably for sit-for to go back to using
> a timer itself.

The reason for not using a timer is so that when a process filter runs
during the sit-for, the expiry of the sit-for won't interrupt the
filter (which might be waiting for keyboard input).  Otherwise,
process filters can't reliably call input reading functions.  See the
thread labelled "a bug of read-passwd" from July.

> One solution to this problem is to bind timer-idle-list to nil while
> calling read-event.

This would inhibit all other idle timers from running during the
sit-for.  But jit-lock-stealth-fontify, for example, sits for 30
seconds, and I don't think we want to inhibit other idle timers during
this entire period.

> The problem is that read-event's call tree ultimately results in
> calling keyboard.c:read_char, which calls timer_start_idle.  This
> resets the activation time for all the current idle timer events,
> which means that any function on an idle timer which calls sit-for
> is now getting scheduled to be run recursively if another interval
> of the appropriate length ensues.

I think the solution is to avoid calling timer_start_idle when
read-event is given a non-nil SECONDS argument.  What do people think?