[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Kim F. Storm
Wed, 02 Aug 2006 01:24:09 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
Chong Yidong <address@hidden> 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 <address@hidden> http://www.cua.dk
- Re: sit-for, Chong Yidong, 2006/08/01
- Re: sit-for,
Kim F. Storm <=