[Top][All Lists]

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

bug#8869: Unjustified selection time-out

From: David De La Harpe Golden
Subject: bug#8869: Unjustified selection time-out
Date: Thu, 16 Jun 2011 02:00:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110606 Icedove/3.1.10

E.g. I suspect the new code sometimes thinks there's a "modern clipboard
manager" running when in reality there simply isn't any.

What does

(x-selection-exists-p 'CLIPBOARD_MANAGER)

return on your system?

Or maybe your
delay is much longer than what is used by other applications.

Emacs uses 20s delay by default (x-selection-timeout), qt/kde and gtk/gnome apps are about 10s (estimated by watching them on my system, didn't dig the exact timeout figure from their sources)

So emacs is waiting twice as long as other apps, but at 10s, I'd still expect the delay in most other apps to be fairly noticeable (for the apps that try to persist at exit at all). Mind you, some other apps' visible/inputoutput windows do disappear at the start rather than end of their wait, though, which might be perceptually hiding the issue. For Qt/KDE apps, watch out for the stderr message "QClipboard: Unable to receive an event from the clipboard manager in a reasonable time" 10 secs after "closing" them.

There's also something of an architectural question raised (though might be a bit late to do anything about it given looming pretest, it's not a showstopper): You're seeing the delay when deleting frames - but there might be ways around emacs asking for its clipboard to be saved in such cases a lot of the time:

Right now a given emacs frame['s x11 window] is used as the selection owner, AFAIUI. When that frame is to be deleted, emacs asks the clipboard manager (if one is detected) to save. But if it's not the last frame opened via a given terminal/display connection, that is a little wasteful.

Emacs doesn't currently keep an extra per-terminal invisible/input-only window lurking (or maybe it does and I just don't know about it) - in contrast AFAICS gtk+ opens a per-process per-display GtkInvisible for owning selections [1][2][3], and Qt probably does something vaguely similar. Emacs could in principle do similar.*

Or if we don't want to do something like that, then I suppose the ownership could be "migrated" to another visible frame on that terminal rather than doing that, "just" set selection owner to another living frame, though that could cause some history-keeping clipboard managers to have duplicate entries (though ones I've used do do dupe checking).

[1] http://developer.gnome.org/gtk/2.24/GtkInvisible.html
[2] http://git.gnome.org/browse/gtk+/tree/gtk/gtkclipboard.c#n451
[3] http://git.gnome.org/browse/gtk+/tree/gtk/gtkinvisible.c#n239

* Well, gtk+ toolkit builds of emacs may wind up with gtk+'s dangling unused and ignored, emacs doesn't use gtk+'s clipboard handling.

reply via email to

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