[Bug: 21.4.12] xemacs: X Error of failedrequest:BadWindow(invalid Window parameter)

[Ben Wing]

> 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

Loop
{
  block until X event ready;
  drain queue;
  check for the event we're looking for and if so remove it from the queue
and exit;
}

To block I think you call XtAppProcessEvent (Xt_app_con, XtIMXEvent);
To do the others, see event_stream_quit_p().