Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Eli Zaretskii <address@hidden> writes:

>> Date: Thu, 01 Sep 2011 14:47:09 +0200
>> From: "Jan D." <address@hidden>
>> CC: Andreas Schwab <address@hidden>, Eli Zaretskii <address@hidden>, 
>>  address@hidden
>> 
>>  From Emacs point of view, localhost:0 and unix:0 and :0 are three 
>> different displays, even if they physically are the same.
>
> Can't we do something in Emacs so it understood that they are on the
> same display?  That won't fix the GTK problem, but at least it will
> work around it in this particular use case.  And I think it's a Good
> Thing in general, no?

Any news on that front?  I'm still accidentally killing emacs at least
twice a day.  And I'm already trying hard not to fire up an emacsclient
X11 frame form external GTK apps, which is really really annoying.  For
example, when I click on a textfile link in a browser, I have to be sure
to save it and then open it from inside emacs, instead of simply letting
the browser invoke emacsclient after which I would have a frame that
would kill emacs when being deleted...

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

For me and I guess for most users, localhost:0, unix:0 (*), :0.0, and :0
are all the same in practice, only localhost:1 or :2 actually mean other
displays.  So I'd simply strip localhost and unix before the colon and
dot-zeros.  (Maybe there should be an option for that, or some lisp
function that would be called to transform the display name if it is
defined...)

Bye,
Tassilo

(*) I'm not too sure with unix:0.  I know such an entry only from
    xorg.conf to tell the xserver where the font server is running.