[Top][All Lists]

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

Re: Killing a frame sometimes kills emacs

From: Tassilo Horn
Subject: Re: Killing a frame sometimes kills emacs
Date: Tue, 11 Oct 2011 16:53:24 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

Stefan Monnier <address@hidden> writes:

Hi Stefan,

>> With resepect to the Emacs 24 release, it's very likely that a lot of
>> users will suffer from this issue, so although it's a gtk bug, there
>> should be some workaround (probably enabled by default).
> I can't imagine why "a lot of users" would run Emacs with different
> (but equivalent) values of $DISPLAY.

They don't do that intentionally, it's a bug in GTK:


[Ulrich, I added you to Cc because you commented on the report above, so
you probably know a bit better about what's going wrong there.]

The problem in my usecase is that when I fire up emacs or emacsclient -c
from the GNOME3 application menu or the run command dialog, it says it
is on DISPLAY :0, i.e., (x-display-list) returns (":0").

In contrast, when I start emacs or emacsclient -c from a GNOME terminal
or the file manager or web browser fire up an emacsclient -c, because
I've set that up as default application for text files, the DISPLAY is

So as soon as I mix these two invocation styles, (x-display-list)
returns (":0" ":0.0").  Those displays are different, and when I delete
the last frame on one of the (equivalent) displays, emacs (including the
original frames on the other displays) are killed.

Not sure who kills emacs.  Reading the bug report above, it seems that
GTK deletes the display, and then emacs crashes because its display is

Maybe a workaround could be to initially tell GTK that emacs runs on
both :0 and :0.0, so that GTK never thinks the last frame is going to be


reply via email to

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