Re: Killing a frame sometimes kills emacs

[Tassilo Horn <tassilo@member.fsf.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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:

  https://bugzilla.gnome.org/show_bug.cgi?id=85715#c55

[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
:0.0.

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
gone.

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
deleted.

Bye,
Tassilo