GNU bug report logs - #8869
Unjustified selection time-out

Previous Next

Full log

Message #8 received at 8869 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 8869 <at> debbugs.gnu.org
Subject: Re: bug#8869: Unjustified selection time-out
Date: Thu, 16 Jun 2011 02:00:31 +0100

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.