Re: sit-for

[storm@cua.dk (Kim F. Storm)]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Since we have the new sit-for implementation, I have a lot of times
>> when Emacs just pauses in busy waiting for input.  This happens
>> spontaneously.  One situation where it happens frequently is when
>> reading news with gnus.
>
> Another possibility just occurred to me.  Unlike the old sit-for, the
> new sit-for is not interrupted by input coming from processes (as
> opposed to user input).  If gnus (or some other package) relies on
> this behavior, a bug will arise.

IMO, sit-for should never be interrupted by input coming from a
subprocess (that is what accept-process-output is for), and code
which relies on that behaviour is wrong.

Process output is _not_ input in the normal sense.  AFAICS, process
output is still read during sit-for and passed to the proper filters
or buffers--so the new sit-for is doing TRT.

>
> The question is: is this a bug of the new sit-for?  If sit-for is
> changed to interrupt due to processes, we have the same problem as
> before: input coming from miscellaneous async processes will interfere
> with towers of hanoi (or other animation code).
>
> One possibility is to bring back the old sit-for with its warts
> (interruptable even if no new input events are available) and change
> the animation code to use `read-event' with its new timeout argument.

That would be a big step backwards!

>
> Another possibility is to leave sit-for as it is, try to find code
> that relies on sit-for returning due to process output, and fix it.

Richard specifically asked [someone] to check all sit-for calls to see
if the new behaviour would break them.  So [we] should already have
done this (but I don't think anybody actually did that).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk