* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-05-30 21:13 ` David De La Harpe Golden
@ 2011-05-30 22:36 ` Stefan Monnier
2011-05-31 1:15 ` Suvayu Ali
2011-06-01 19:01 ` Chong Yidong
2 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2011-05-30 22:36 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Chong Yidong, Suvayu Ali, 8760
> Arguably, Emacs, if it's in the middle of exiting, could just carry on
> exiting after the selection timeout period in case it fails to interact
> with a present but uncommunicative clipboard manager, not fail
> to exit.
That would the right behavior, tho it's also important to somehow warn
the user about the problem. Yes, could someone do that?
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-05-30 21:13 ` David De La Harpe Golden
2011-05-30 22:36 ` Stefan Monnier
@ 2011-05-31 1:15 ` Suvayu Ali
2011-05-31 2:58 ` David De La Harpe Golden
2011-06-01 19:01 ` Chong Yidong
2 siblings, 1 reply; 9+ messages in thread
From: Suvayu Ali @ 2011-05-31 1:15 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Stefan, Chong Yidong, 8760
Hello David,
On Mon, 30 May 2011 22:13:20 +0100
David De La Harpe Golden <david@harpegolden.net> wrote:
> On 30/05/11 08:12, Suvayu Ali wrote:
> > Hi Emacs developers,
> >
> > After I updated Emacs today, I found a very annoying bug.
> >
> > If I copy/kill something to the kill-ring, I can't exit emacs with
> > 'C-x C-c'. Attempting to do so results in the following backtrace:
> >
> > Debugger entered--Lisp error: (error "Timed out waiting for reply
> > from selection owner") kill-emacs()
> > save-buffers-kill-emacs(nil)
> > save-buffers-kill-terminal(nil)
> > call-interactively(save-buffers-kill-terminal nil nil)
> >
>
> *** What desktop environment do you use, if any? (KDE, GNOME,
> XFCE, ...) (and what version?)
>
I use XFCE with the clipman plugin (its a clipboard manager).
> Emacs was just expanded to communicate with a desktop environment's
> clipboard manager if available, which allows things you copy to
> persist on the clipboard after you exit emacs.
>
Yes I had noticed that over the last month or two. It was working very
well until now.
> However, in your case something is going wrong, it sounds like you
> have a daemon around claiming to be a clipboard manager (because
> emacs is trying to talk to it at all) but it's acting weird (emacs
> getting a timeout trying to talk with it).
>
> I can simulate this failure by pausing (kill -STOP/-CONT) my desktop
> environment's clipboard manager - that way, it looks like there's an
> owner of the clipboard manager selection that is unresponsive.
>
I tried the same steps in a fresh XFCE session without clipman, I
still get the same results. I am not very familiar with the internals
of XFCE, not sure how the default XFCE clipboard is managed.
> Arguably, emacs, if it's in the middle of exiting, could just carry
> on exiting after the selection timeout period in case it fails to
> interact with a present but uncommunicative clipboard manager, not
> fail to exit. Then the worst that happens in case of a malfunctioning
> desktop clipboard manager is a brief pause on exit (and of course a
> failure to persist clipboard contents after exit, but, well, one
> can't expect that to work if the desktop clipboard manager isn't
> working).
>
That would be a reasonable behaviour. :)
> > I am not subscribed to the dev list
>
> Please just be sure to keep the bug email address (8760@debbugs...)
> in the to/cc list for this thread, then it gets archived by the bug
> tracker.
>
Thanks for that tip, will keep that in mind from now.
For some reason I did not get your or Stefan's response despite both of
you CC'ing me. I downloaded your message from the bug tracker and am
responding to it so the threading might be screwed up. Its probably a
Gmail issue.
Thanks,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-05-31 1:15 ` Suvayu Ali
@ 2011-05-31 2:58 ` David De La Harpe Golden
2011-05-31 3:49 ` Suvayu Ali
0 siblings, 1 reply; 9+ messages in thread
From: David De La Harpe Golden @ 2011-05-31 2:58 UTC (permalink / raw)
To: Suvayu Ali; +Cc: Chong Yidong, 8760
On 31/05/11 02:15, Suvayu Ali wrote:
> I tried the same steps in a fresh XFCE session without clipman, I
> still get the same results.
That does suggest it's a problem with xfce's default clipboard manager.
They recently reimplemented that. You may still be running an older
known-buggy one.
> I am not very familiar with the internals
> of XFCE, not sure how the default XFCE clipboard is managed.
There's a clipboard manager hiding inside xfce4-settings-helper.
Please try the following command at the shell to print its version and
report the results:
xfce4-settings-helper -V
If it's less than 4.8.2, you may have the buggy version. It can cause
similar problems with other apps too [1]. (That doesn't change the fact
emacs should be exiting after timing out, of course).
> For some reason I did not get your or Stefan's response despite both of
> you CC'ing me. I downloaded your message from the bug tracker and am
> responding to it so the threading might be screwed up. Its probably a
> Gmail issue.
>
Irritating. FWIW, my mailserver says it successfully handed the mail to
google. Hopefully this one will reach you less awkwardly.
[1] https://bugzilla.xfce.org/show_bug.cgi?id=7588
"xfce4-settings-4.8.2 contains the gsd clipboard that should resolve
this bug."
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-05-31 2:58 ` David De La Harpe Golden
@ 2011-05-31 3:49 ` Suvayu Ali
0 siblings, 0 replies; 9+ messages in thread
From: Suvayu Ali @ 2011-05-31 3:49 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Stefan, Chong Yidong, 8760
Hi David,
On Tue, 31 May 2011 03:58:02 +0100
David De La Harpe Golden <david@harpegolden.net> wrote:
> On 31/05/11 02:15, Suvayu Ali wrote:
>
> > I am not very familiar with the internals
> > of XFCE, not sure how the default XFCE clipboard is managed.
>
> There's a clipboard manager hiding inside xfce4-settings-helper.
> Please try the following command at the shell to print its version
> and report the results:
>
> xfce4-settings-helper -V
>
> If it's less than 4.8.2, you may have the buggy version. It can cause
> similar problems with other apps too [1]. (That doesn't change the
> fact emacs should be exiting after timing out, of course).
>
xfce4-settings-helper 4.8.1 (Xfce 4.8.0)
My version is indeed the buggy version. I am on Fedora 15, I will take
this up with the Fedora XFCE team.
> > For some reason I did not get your or Stefan's response despite
> > both of you CC'ing me. I downloaded your message from the bug
> > tracker and am responding to it so the threading might be screwed
> > up. Its probably a Gmail issue.
> >
>
> Irritating. FWIW, my mailserver says it successfully handed the mail
> to google. Hopefully this one will reach you less awkwardly.
>
This one reached properly. :)
Thanks a lot. I hope I have provided enough information to fix the Emacs
end of this issue. :)
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-05-30 21:13 ` David De La Harpe Golden
2011-05-30 22:36 ` Stefan Monnier
2011-05-31 1:15 ` Suvayu Ali
@ 2011-06-01 19:01 ` Chong Yidong
2011-06-02 3:01 ` David De La Harpe Golden
2 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2011-06-01 19:01 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Suvayu Ali, 8760
David De La Harpe Golden <david@harpegolden.net> writes:
> I can simulate this failure by pausing (kill -STOP/-CONT) my desktop
> environment's clipboard manager - that way, it looks like there's an
> owner of the clipboard manager selection that is unresponsive.
>
> Arguably, emacs, if it's in the middle of exiting, could just carry on
> exiting after the selection timeout period in case it fails to
> interact with a present but uncommunicative clipboard manager, not
> fail to exit. Then the worst that happens in case of a malfunctioning
> desktop clipboard manager is a brief pause on exit (and of course a
> failure to persist clipboard contents after exit, but, well, one can't
> expect that to work if the desktop clipboard manager isn't working).
Right. Does this patch handle your test case properly?
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.
=== modified file 'src/xselect.c'
*** src/xselect.c 2011-05-29 05:23:24 +0000
--- src/xselect.c 2011-06-01 18:55:25 +0000
***************
*** 2112,2122 ****
UTF8_STRING property, as described by
http://www.freedesktop.org/wiki/ClipboardManager */
! static void
! x_clipboard_manager_save (struct x_display_info *dpyinfo,
! Lisp_Object frame)
{
struct frame *f = XFRAME (frame);
Atom data = dpyinfo->Xatom_UTF8_STRING;
XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
--- 2112,2122 ----
UTF8_STRING property, as described by
http://www.freedesktop.org/wiki/ClipboardManager */
! static Lisp_Object
! x_clipboard_manager_save (Lisp_Object frame)
{
struct frame *f = XFRAME (frame);
+ struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
Atom data = dpyinfo->Xatom_UTF8_STRING;
XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
***************
*** 2148,2154 ****
&& EQ (frame, XCAR (XCDR (XCDR (XCDR (local_selection)))))
&& XGetSelectionOwner (dpyinfo->display,
dpyinfo->Xatom_CLIPBOARD_MANAGER))
! x_clipboard_manager_save (dpyinfo, frame);
}
}
--- 2148,2155 ----
&& EQ (frame, XCAR (XCDR (XCDR (XCDR (local_selection)))))
&& XGetSelectionOwner (dpyinfo->display,
dpyinfo->Xatom_CLIPBOARD_MANAGER))
! internal_condition_case_1 (x_clipboard_manager_save,
! frame, Qt, Fidentity);
}
}
***************
*** 2172,2178 ****
local_frame = XCAR (XCDR (XCDR (XCDR (local_selection))));
if (FRAME_LIVE_P (XFRAME (local_frame)))
! x_clipboard_manager_save (dpyinfo, local_frame);
}
}
--- 2173,2180 ----
local_frame = XCAR (XCDR (XCDR (XCDR (local_selection))));
if (FRAME_LIVE_P (XFRAME (local_frame)))
! internal_condition_case_1 (x_clipboard_manager_save,
! local_frame, Qt, Fidentity);
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-06-01 19:01 ` Chong Yidong
@ 2011-06-02 3:01 ` David De La Harpe Golden
2011-06-04 21:04 ` Chong Yidong
0 siblings, 1 reply; 9+ messages in thread
From: David De La Harpe Golden @ 2011-06-02 3:01 UTC (permalink / raw)
To: Chong Yidong; +Cc: Suvayu Ali, 8760
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"
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
2011-06-02 3:01 ` David De La Harpe Golden
@ 2011-06-04 21:04 ` Chong Yidong
0 siblings, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2011-06-04 21:04 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Suvayu Ali, 8760
David De La Harpe Golden <david@harpegolden.net> writes:
> 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.
I guess that's the best we can hope for. I've committed some changes to
handle clipboard manager errors in this way. I'm closing this bug; we
can consider Bug#8779 separately.
^ permalink raw reply [flat|nested] 9+ messages in thread