bug#8869: Unjustified selection time-out

[David De La Harpe Golden <david@harpegolden.net>]

On 16/06/11 14:44, Stefan Monnier wrote:
>> What does
>> (x-selection-exists-p 'CLIPBOARD_MANAGER)
>> return on your system?
>
> It returns t.
>

So, well, it does sound like you do have something that looks like a 
clipboard manager hanging about  ...but what? (i.e. what process is the 
owner of that selection...).  Of course, if other apps aren't being 
affected, maybe it is an issue with emacs rather than the clipboard 
maanger.  But to investigate further, it would still be good to know 
what version of what clipboard manager you're running (even if you 
didn't know you were running one...).

ISTR you once mentioning you used a fairly old-school desktop setup, 
don't know what you're using now - given you mention gnome-terminal, 
though, can you see if you have the "gnome-settings-daemon" process 
hanging around? It's a clipboard manager among other things.

I'm a bit slow to blame the new code, as we've already seen one buggy 
clipboard manager (a particular version of xfce4-settings-helper, now 
superseded).  We did also have one user report a problem under their 
gnome desktop, but neither Chong Yidong nor myself could replicate it 
(#8779).

> I don't actually know which application other than Emacs implements this
> protocol, but gnome-terminal exits in less than 1s, same for Firefox
> (well, it might take a bit more than 1s for Firefox, but it's still
> pretty close).
>

gnome-terminal was one of the apps I tested with, it takes 10 secs to 
timeout on my system if I make my clipboard manager malfunction in such 
a way that it still claims to exist but doesn't work (and of course have 
just copied in gnome-terminal). Testing firefox (or actually iceweasel) 
it takes a bit over 10 secs too.

Uh. Can you start from a fresh emacs -Q and reliably replicate the 
issue, or is it only happening sometimes even considering only those 
times you've just copied in emacs?