bug#37352: 27.0.50; recursive-edit aborts on elisp error after evaluation

[Drew Adams <drew.adams@oracle.com>]

> > > I don't know why the `q' command in the debugging mode
> > > is defined that way.
> >
> > Uh, because it makes sense?  The recursive edit
> > was entered only for use of the debugger.
> 
> There are two recursive edits, one that the OP entered from their code
> (I assume for the edit-file-and-return-as-string stuff [1]), 

Sorry; didn't realize that.

> and a second nested one that happend after an error was signaled and the
> debugger was invoked. Then quitting the debugger exits both recursive
> edits, because q is bound to top-level in debugger-mode, and top-level
> aborts all recursive edits, not just the latest one.
> 
> A possible solution might be to bind q to a command which quits
> recursive edits only up to the one that the debugger invoked.

I see; thanks.

But if an error was raised then is it possible to return
from the debugger recursive edit to the previous recursive
edit?  Continuing from an error can be problematic, no?

On the other hand, if the debugger was entered for, say,
`debug` or `debug-on-entry` then what's called for is to
use `c`, not `q`, (as many times as necessary, to exit the
debugger), or to use `C-M-c` to exit the recursive edit
immediately.