[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:1.9.2.17) 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.
- bug#8869: Unjustified selection time-out, Stefan Monnier, 2011/06/15
- bug#8869: Unjustified selection time-out,
David De La Harpe Golden <=
- bug#8869: Unjustified selection time-out, Jan D., 2011/06/16
- bug#8869: Unjustified selection time-out, Stefan Monnier, 2011/06/16
- bug#8869: Unjustified selection time-out, David De La Harpe Golden, 2011/06/16
- bug#8869: Unjustified selection time-out, Stefan Monnier, 2011/06/16
- bug#8869: Unjustified selection time-out, David De La Harpe Golden, 2011/06/17
- bug#8869: Unjustified selection time-out, Chong Yidong, 2011/06/18
- bug#8869: Unjustified selection time-out, Jan Djärv, 2011/06/19
- bug#8869: Unjustified selection time-out, Jan Djärv, 2011/06/19
- bug#8869: Unjustified selection time-out, Chong Yidong, 2011/06/25
- bug#8869: Unjustified selection time-out, Jan Djärv, 2011/06/26