bug#8869: Unjustified selection time-out

[Jan Djärv]

Hi.

There is something wrong with the implementation for SAVE_TARGETS.
What happens is:

1) Emacs sends SAVE_TARGET and starts to wait for SelectionNotify.
2) The clipboard manager tries to get the CLIPBOARD selection with a
   SelectionRequest.
3) Emacs receives this but does not reply to it, as it is only intereted in
   SelectionNotify.
4) If an input event, such as mouse move, occurs, the loop is broken and all
   queued X Events are handeled, including SelectionRequest.
5) The clipboard manager has gotten the clipboard from Emacs and only now
   sends SelectionNotify.

Thus, if there isn't any input in 4), the exit will time out.
Emacs must handle SelectionRequest in 3) to work correctly.

        Jan D.


Chong Yidong skrev 2011-06-19 00.03:
> David De La Harpe Golden<david@harpegolden.net>  writes:
>
> > > - standard Debian testing Gnome setup.
> > > - killall metacity.
> > > - start good'ol ctwm, emacs, and xterm.
> >
> > Well, if you're literally doing that, that will tend to leave bits of
> > gnome hanging about.
>
> Yeah, though that doesn't explain why "no other application seems to
> exhibit such a delay when exiting".  Plenty of other applications ought
> to be supporting the clipboard manager spec these days.
>
> There are various possible workarounds, e.g. we could have
> x_clipboard_manager_save_frame set x-select-enable-clipboard-manager to
> nil if it hits a timeout, so that the delay at least won't recur in the
> same session.  But it wouldn't be wise to implement them until we get a
> few more details about the actual failure case.