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