@tfb does that preempt graphical things, like my browser? Sometimes I have to switch to a system terminal with eg `C-M f2` to debug something breaking my emacs, but I don't believe I can get a GUI app up from there
@worldsendless My ild startup sequence was: xinit launches an xterm/urxvt which starts screen (these days I'd use tmux), which then starts the WM.
You can always reconnect to the tmux session from another system terminal or even ssh, to affect your X session. A bit of a Rube Goldberg machine, but it works
@worldsendless you might be able to use the profiler (M-x profiler-start, profiler-report) to identify the culprit. It's often an unexpectedly expensive hook. For example in my case ibuffer-auto-mode's post-command-hook was slowing things down so I ended up making a custom version.
@zrzz That is an excellent idea! In fact, hooks indeed sound like a likely culprit, the sort of thing that accumulates over emacs run time. Next time I have the slowdown, I will definitely do the profiler
@worldsendless A trick I used many years ago when using questionably reliable window managers, was to start a terminal rather than a WM as the root X11 process. Then start the WM from there. If ever you need to restart the WM, you can exit it, and start it anew from that terminal. Combined with
desktop-save-mode, that should make restarting Emacs pretty low-impact