bug#16737: Timed out waiting for reply from selection owner

[Tom Tromey <tom@tromey.com>]

Jan> If it times out, it is because we don't get the PropertyNotify we
Jan> expect.  There is some TRACE one can turn on in xselect.c by
Jan> defining TRACE_SELECTION.

FWIW, this bug bites me enough that I have basically had to stop pasting
into Emacs.  This is no good!

However, I still don't know the sequence to recreate the bug.  For
instance it didn't happen right away with "emacs -Q".  All I know is
that it happens to me in basically any normal emacs session I try, and
that sometimes it works for a while before breaking.


I did do a little debugging tonight.  One thing I found is that the
correct selection notify event does arrive.  I set a breakpoint in
x_handle_selection_notify and I see a matching event come in.

However, the event arrives after x_get_foreign_selection returns.  I
think this is what is unexpected -- the event ought to be processed by
the call to wait_reading_process_output there.

When the event does arrive, if I go up the stack I see gobble_input.  I
don't know this area well but maybe it would work to either disable the
SIGIO code, or to call gobble_input before calling
wait_reading_process_output.

If I debug "emacs -Q" and paste, what I see is that
x_get_foreign_selection calls unblock_input and that this causes the
event to be read.  I don't know why this isn't done in the failing case.

Any suggestions?  I can't promise much but maybe I could try something
out.

Tom