[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16737: Timed out waiting for reply from selection owner
From: |
Tom Tromey |
Subject: |
bug#16737: Timed out waiting for reply from selection owner |
Date: |
Fri, 21 Nov 2014 03:53:49 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#16737: Timed out waiting for reply from selection owner,
Tom Tromey <=