[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:1.9.2.17) 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.
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"