From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: sit-for
Date: Wed, 02 Aug 2006 01:24:09 +0200 [thread overview]
Message-ID: <m364hc3uqu.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <877j1spg1d.fsf@stupidchicken.com> (Chong Yidong's message of "Tue, 01 Aug 2006 12:38:38 -0400")
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
next prev parent reply other threads:[~2006-08-01 23:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 21:06 sit-for David Kastrup
2006-07-28 21:48 ` sit-for Chong Yidong
2006-07-29 7:15 ` sit-for David Kastrup
2006-07-29 8:40 ` sit-for David Kastrup
2006-07-29 14:43 ` sit-for Chong Yidong
2006-07-30 22:36 ` sit-for Kim F. Storm
2006-07-31 18:29 ` sit-for Richard Stallman
2006-07-29 23:34 ` sit-for Richard Stallman
2006-07-29 23:34 ` sit-for Richard Stallman
2006-08-02 0:05 ` sit-for Chong Yidong
2006-08-02 6:09 ` sit-for David Kastrup
2006-08-01 16:38 ` sit-for Chong Yidong
2006-08-01 23:24 ` Kim F. Storm [this message]
2006-08-01 23:52 ` sit-for Chong Yidong
2006-08-02 6:06 ` sit-for David Kastrup
2006-08-03 15:50 ` sit-for Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m364hc3uqu.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.