Re: Problem with `while-no-input'

[Eli Zaretskii <eliz@gnu.org>]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Sat, 11 Mar 2006 12:35:49 +0000
> Cc: emacs-devel@gnu.org, storm@cua.dk, klaus.berndl@sdm.de
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >     Hmm, would it not better, to enable while-not-input also working with Windows? ;-)
> >
> > Yes, it would be better, but that may be very difficult.  (I don't
> > know.)  We should document it if we can't fix it.
> 
> I think the relevant code is in keyboard.c in the POLL_FOR_INPUT
> conditional blocks. Currently this code handles detection of C-g
> according to the comments, I do not know why it manages to do that
> without also handling general detection of input.

Jason, I'm looking at keyboard.c, and I don't understand what you are
saying.  Are you saying that POLL_FOR_INPUT code is used by Windows,
and that it should handle this case, but currently only handles C-g?
Or are you saying that the POLL_FOR_INPUT code detects both C-g and
any other sorts of input, but somehow, only on Windows, non-C-g input
goes undetected?

Anyway, I see in w32fns.c:post_character_message that C-g is handled
specially in this function.  When we detect C-g, we signal the special
interrupt_handle.  However, I'm not quite sure who and how sees that
this handle is signaled: sys_select isn't called while the body of
while-no-input runs in this case, since that body is pure Lisp code,
right?  What am I missing?

I also see in the debugger that, when the while-no-input form runs,
w32_read_socket is not called.  I think this explains why Emacs
doesn't see the input, and doesn't interrupt the form's body:
w32_read_socket is the only way to receive input on Windows, right?

I think we can arrange for _any_ input to interrupt a while-no-input
form, but this needs to be done from w32_wnd_proc (which is in another
thread, right?).  Do you think this is a good approach?