bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[David De La Harpe Golden]

On 01/06/11 20:01, Chong Yidong wrote:

> Right.  Does this patch handle your test case properly?

Yes, deleting frames and exiting, though of course there's the expected 
pause. It is quite long enough that people will notice and probably file 
bug reports. But I don't think reducing the timeout much is a good idea 
either, people after all could genuinely be on a slow connection...

> One concern I have is that even if the clipboard manager is screwing up,
> it will appear as though it's Emacs' fault for taking ages to delete a
> frame and/or shut down.

Indeed.

>  Dunno how we can inform the user, though.

Well, for the x_clipboard_manager_save_frame case, then a normal message 
should suffice? they'll see it in another of their remaining frames.

For the x_clipboard_manager_save_all - printing something to the emacs 
process stderr before exit might be simplest. But could be missed.

Popping up dialogs / interactive prompts seems overly intrusive to me, 
but is probably an option.

I suppose one could show a message too - if one messaged before starting 
the save, then it would rapidly flash by except in the case it's taking 
ages, but at least bug reports would come in with the text of the 
message. Except that means letting redisplay happen...

If the user has sat through the timeout, showing a message for a few 
secs post-timeout is only a small incremental time wasting, but still 
involves letting more redisplay happen.

What to say?

"Timeout communicating with your desktop environment clipboard manager"