[Top][All Lists]

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

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

From: David De La Harpe Golden
Subject: bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
Date: Thu, 02 Jun 2011 04:01:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110510 Icedove/3.1.10

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.


 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"

reply via email to

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