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