one emacs process for wm and everything else? #120

thk commented 2026年06月24日 16:43:42 +02:00

Do you use one single emacs instance to manage windows and to do your editing and everything else you do in Emacs?

I wonder:
a) How dangerous this is. Emacs could block or crash and thus block or kill everything with it.
b) How I could iterate on my emacs config without having to reboot the whole session.

Or do you use one emacs process just for window management and another emacs process for everything else?

Or is there a way to restart emacs without killing everything else, e.g. with some help from detached.el?

This question actually also applies to EXWM and rika as far as I understand these projects.

Thank you!

Do you use one single emacs instance to manage windows and to do your editing and everything else you do in Emacs? I wonder: a) How dangerous this is. Emacs could block or crash and thus block or kill everything with it. b) How I could iterate on my emacs config without having to reboot the whole session. Or do you use one emacs process just for window management and another emacs process for everything else? Or is there a way to restart emacs without killing everything else, e.g. with some help from detached.el? This question actually also applies to EXWM and rika as far as I understand these projects. Thank you!

ezemtsov commented 2026年06月24日 16:58:16 +02:00

Hi! Thanks for the great question and welcome :)

Technically it's the single emacs session for both editing and window management, but the actual rendering loop is running a separate thread, so even if emacs is stuck in something, your graphical windows and other compositor features work just fine.

The architectural model of ewm is that emacs is mostly only used to spawn the applications and position them correctly within the buffers, but it never used in the main rendering loop.

Even with this phrasing, it indeed still can be dangerous if you're using a lot of synchronous processes that can block the main emacs thread. In practice though, to my experience with exwm before and now ewm, if your configuration is reasonably lightweight this rarely happens.

So:

• Ewm starts emacs daemon, the daemon spawns the compositor thread. All applications and the compositor have emacs thread as parent.
• Reka is different in architecture, and the river process is detached from emacs, which makes it possible to restart emacs without losing the graphical session.

I highly recommend to try any of the tools we mention here! It's an amazing way to experiment and learn more about the emacs ecosystem, and with a decent configuration have a very reliable long running graphical sessions.

Hi! Thanks for the great question and welcome :) Technically it's the single emacs session for both editing and window management, but the actual rendering loop is running a separate thread, so even if emacs is stuck in something, your graphical windows and other compositor features work just fine. The architectural model of ewm is that emacs is mostly only used to spawn the applications and position them correctly within the buffers, but it never used in the main rendering loop. Even with this phrasing, it indeed still can be dangerous if you're using a lot of synchronous processes that can block the main emacs thread. In practice though, to my experience with exwm before and now ewm, if your configuration is reasonably lightweight this rarely happens. So: - Ewm starts emacs daemon, the daemon spawns the compositor thread. All applications and the compositor have emacs thread as parent. - Reka is different in architecture, and the river process is detached from emacs, which makes it possible to restart emacs without losing the graphical session. I highly recommend to try any of the tools we mention here! It's an amazing way to experiment and learn more about the emacs ecosystem, and with a decent configuration have a very reliable long running graphical sessions.

thk commented 2026年07月03日 16:41:59 +02:00

Thanks a lot for the explanation especially also to reka!

I've started exploring reka first, but I'm not sure yet, whether it'd really be possible to restart emacs without loosing the session. I start however to get comfortable with the thought to rely on emacs being stable and responsive enough to trust it with my session.

River (which reka uses) starts a session (or process) leader process. This could process commonly is a shell script that eventually starts the actual window manager (emacs with reka), e.g. via systemctl start --wait. In this case it is possible to restart emacs with systemctl restart since the previous systemctl call keeps waiting during a restart.

However if one wants to change the emacs config and there is a problem, the session still ends.

And even with a successful restart I'm not sure whether reka wouldn't kill all windows during emacs shutdown and if it doesn't it would have lost all managed state.

For now I keep exploring and leave this worry for another time.

My dream for an emacs window manager would be to have a minimal process as session leader, much like a minimal init process. Emacs communicates with this minimal process and can recover state from it.

The minimal process has a fallback mechanism: If no emacs connects after a timeout, then it will show a terminal emulator fullscreen. Once emacs comes back, the terminal emulator window gets managed by emacs.

Please feel free to close this issue so that I don't pollute your project!

Thanks a lot for the explanation especially also to reka! I've started exploring reka first, but I'm not sure yet, whether it'd really be possible to restart emacs without loosing the session. I start however to get comfortable with the thought to rely on emacs being stable and responsive enough to trust it with my session. River (which reka uses) starts a session (or process) leader process. This could process commonly is a shell script that eventually starts the actual window manager (emacs with reka), e.g. via `systemctl start --wait`. In this case it is possible to restart emacs with `systemctl restart` since the previous systemctl call keeps waiting during a restart. However if one wants to change the emacs config and there is a problem, the session still ends. And even with a successful restart I'm not sure whether reka wouldn't kill all windows during emacs shutdown and if it doesn't it would have lost all managed state. For now I keep exploring and leave this worry for another time. My dream for an emacs window manager would be to have a minimal process as session leader, much like a minimal init process. Emacs communicates with this minimal process and can recover state from it. The minimal process has a fallback mechanism: If no emacs connects after a timeout, then it will show a terminal emulator fullscreen. Once emacs comes back, the terminal emulator window gets managed by emacs. Please feel free to close this issue so that I don't pollute your project!