bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8869: Unjustified selection time-out


From: Jan Djärv
Subject: bug#8869: Unjustified selection time-out
Date: Sun, 19 Jun 2011 12:26:56 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.18) Gecko/20110613 Thunderbird/3.1.11

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<address@hidden>  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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]