[Bug: 21.4.12] xemacs: X Error of failedrequest:BadWindow(invalid Window parameter)
ben at 666.com
Mon Nov 22 22:15:10 EST 2004
> Right, so anything larger than ~4Mb will result in the use of
> an incremental transfer. This is the case where
> wait_delaying_user_input() gets called, and that's where the
> problem appears to lie.
> Incremental selections involve the selection owner storing a
> chunk of the selection on a property, waiting for the
> requestor to delete it, storing the next chunk, and so on.
> The owner has to wait for a PropertyNotify event indicating
> that the requestor has deleted the property before storing
> the next chunk. To do this, XEmacs calls
> next_event_internal() to obtain the next event. If it is a
> command event or an eval or magic_eval event, it enqueues it
> for later processing, otherwise it dispatches it.
> One issue is that dispatching events may have consequences
> which the incremental selection code wasn't expecting. E.g.
> further SelectionRequest events may be processed while an
> existing transfer is underway (pasting into an xterm results
> in multiple requests, for UTF8_STRING, TEXT and COMPOUND_TEXT).
I think you're right that XEmacs should be delaying *all* events except the
one it is looking for. When the selection code was written there was only
the "command event queue" and maybe there are problems putting non-user
events there; certainly it wasn't designed for it. But now there is also
the "dispatch event queue" which just stores events taken directly from the
window system -- e.g. for quit processing to work well you need to snarf all
pending events so you can look through them. It seems like you could just
go into a loop something like
block until X event ready;
check for the event we're looking for and if so remove it from the queue
To block I think you call XtAppProcessEvent (Xt_app_con, XtIMXEvent);
To do the others, see event_stream_quit_p().
More information about the XEmacs-Beta