[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: Suvayu Ali
Subject: bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring
Date: Mon, 30 May 2011 18:15:57 -0700

Hello David,

On Mon, 30 May 2011 22:13:20 +0100
David De La Harpe Golden <address@hidden> 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  (address@hidden)
> 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.



Open source is the future. It sets us free.

reply via email to

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