Emacs' recursive edit, service with a bug?

While using query-replace I entered into the recursive edit mode – I've struggled to use this in the past for any great effect.. – so its no wonder I managed to /leave/ this mode on.

Later on during my session I tried to start up an emacsclient (with -nw to use the tty in a terminal emulator) and found that Emacs didn't want to respond to any keypress :(

Well. What do you do? You turn to a debugging tool of course! In this case, I have the handy M-x doom/toggle-profiler command to use from the excellent doom-emacs framework. This command toggles the CPU and memory profilers that Emacs has built in to the “on” position and records away. So, after starting the profiler all I had to do was start up my emacsclient client again and see what the heck was going on.

In my head I thought it could be:

  1. An issue with my unusual invocation (fzf | xargs --open-tty --no-run-if-empty -t -- emacsclient -nw)
  2. The main loop was stuck on a piece of code
  3. $TERM, Emacs, and the terminal's tcinfo were in disagreement and could be spewing unknown/unhandled control characters around

Without digging into things to hard I found that the recursive edit was still in progress.. because it was the parent frame for every other frame recorded:

Note that the top frames are from first starting query-replace!

Neat.

Exiting the recursive edit fixed the locked sessions and everything is working much better now :)

Can't say its a bug for sure – yet – because I'd need to try coming at this from the repro case to make a helpful report. Which I just might do.