Hacker News Reader

Comment by omnicognate | Hacker News Reader

Re EXWM and:

> Emacs is single threaded, therefore if anything in the system hangs, the whole system hangs

For development work I haven't found this to be an issue. Generally when coding I use very few X apps - pretty much just a web browser and maybe occasionally a PDF preview or docs browser. I don't think I've ever had a problem with the single-threaded behaviour blocking window management there. (And as an aside, while proper threading would be nice for things that actually should be concurrent - such as EXWM's duties as a window manager - I massively prefer emacs' synchronous processing of input over the JetBrains horror of pressing a key combination and then having to wait for some asynchronous UI behaviour to occur, with different outcomes depending on whether the next keypress occurs before or after the UI behaviour the first one triggered.)

For other, more GUI-focused activities I just run a separate (wayland) session.

View on HN

I live in EXWM. I absolutely love it as a coding environment. EXWM + helm + projectile. I mainly use v-term for cli, but I have always been interested in learning eshell, just never got around to it. I have been thread-locked on occasion, and when that happens it is frustrating. I can sometimes manage to switch to another session to kill processes and avoid restart, but not always. Still, I wouldn't leave EXWM. Maybe in my retirement I will end my career by helping to make emacs + EXWM multi threaded. I am guessing that is a daunting project, but it sure would be fulfilling.

If you want to try eshell, try combining it with EAT (eat-eshell-mode).

> Maybe in my retirement I will end my career by helping to make emacs + EXWM multi threaded. I am guessing that is a daunting project, but it sure would be fulfilling.

This isn't fixable with threads, unfortunately. The issue is that:

1. Emacs e.g., launches a process with call-process. This blocks EVERYTHING (including other threads). 2. That process wants to map the window but EXWM can't respond to this request because Emacs is blocked. 3. The call to call-process never returns because the process can't create its window.

You'd have to fix Emacs to not block everything in cases like this, but that has been tried before: https://mail.gnu.org/archive/html/emacs-devel/2023-06/msg007...

At this point, I think the right answer is to write a minimal out-of-process window manager (e.g., a wayland compositor).

1. During normal operation, it would behave like EXWM and ask Emacs how to manage windows, etc. 2. In special cases (TBD), it would behave autonomously, acting like a standard floating window manager until Emacs becomes responsive again.

Thank you stebalien, I will remember these points about EXWM / emacs and concurrency. I'll look into EAT as well.

I don’t imagine I’d want to use my general emacs as my window manager, I imagine the sanest way would be to run two instances of emacs.

I absolutely love Emacs, but I can't understand why people want it to be their window manager, of all things. Emacs can be many things, but high performance it is not. And WMs definitely are a high performance area.

They’re really not. Stability matters, but a wm has very little to do with actual rendering, it’s more placement, title bar and decorations, emacs as slow as it can be would be perfectly fine unless you have some crazy extensions on top, hence running two instances.

Fair. Regardless, it just seems like an odd tool for the job.

I do have a wandering eye for EXWM, it probably would require my skill with emacs to increase and an optimization of my config so as to defer heavy tasks etc. If you have any suggestions on how to get there, I am all ears! The more I use emacs, the more I want to make my entire computer emacs.

You likely don't need to optimize anything; Emacs has seen some pretty significant optimizations recently (native Emacs Lisp compilation, tree-sitter modes, better handling of long lines, etc.) so performance is rarely the issue.

However, you do need to avoid call-process (spawning blocking processes) as much as possible. Also, my experience with TRAMP has been pretty awful due to the fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145 (literally: TRAMP blocks all of Emacs while waiting on a network connection).

Reply on news.ycombinator.com