There's this relatively minor Emacs bug that I've been aware of for a long time, years. The basic drift is that on Linux systems, when running with GTK/Emacs as a daemon, and the X11 session terminates for any reason the Emacs daemon terminates. Emacs daemons are great: you start Emacs once, and it keeps running independently of what ever windows you have open. You can leave files open in Emacs buffers and not have move between different projects with minimal context switching costs.
First of all, emacs's daemon mode is weird. I can't think of another application that starts as a daemon (in the conventional UNIX double-forking manner,) and then a client process runs and spawns GUI (potentially) windows. If there are other applications that work this way, there aren't many.
Nevertheless, being able to restart the window manager without loosing the current state of your Emacs session is one of the chief reasons to run Emacs in daemon mode, so this bug has always been a bit irksome. Also since it's real, and for sure a thing, why has it taken so long to address? Lets dig a little bit deeper.
There are two GNOME bugs related to this:
What's happening isn't interesting or complicated: Emacs calls an API, which behaves differently than Emacs expects and needs, but not (particularly) differently than GNOME expects or needs. Which means GNOME has little incentive to fix the bug--if they even could without breaking other users of this API.
Emacs can't fix the problem on their own, without writing a big hack around GNOME components, which wouldn't be particularly desirable or viable, and because this works fine with the other toolkit (and is only possible in some situations,) it doesn't feel like an Emacs bug.
We have something of a stalemate. Both party thinks the other is at fault. No one is particularly incentivized to fix the problem from their own code, and there is a work around, [1] albeit a kind of gnarly one.
This kind of issue feels, if not common, incredibly easy for a project--even one like emacs--to stumble into and quite easy to just never resolve. This kind of thing happens, in some form, very often and boundaries between libraries make it even more likely.
On the positive side, It does seem like there's recent progress on the issue, so it probably won't be another 10 years before it gets fixed, but who knows.
| [1] | To avoid this problem either: don't use GUI emacs windows and just use the terminal (fairly common, and more tractable as terminal emulators have improved a bunch in the past few years,) or use the Lucid GUI toolkit, which doesn't depend on GTK at all. The lucid build is ugly (as the widgets don't interact with GTK settings,) but its light weight and doesn't suffer the ' |