Re: Emacs routinely gets stuck in single_kboard mode

[lorentey@elte.hu (Lőrentey Károly)]

Richard Stallman <rms@gnu.org> writes:
>     > A recursive edit or debug session must set single_kboard,
>     > because the environment of the recursive edit or debug session
>     > would otherwise be imposed on all the other terminals.
>
>     I see, but if there are multiple frames, then that recursive
>     environment is imposed on them, and AFAICS in that case this only
>     results in some small inconveniences that are easy to work around.
>
> Sorry, I don't follow what you're saying here.
> The other terminals won't see the buffer that the recursive
> edit or debug session is in, and there is potential
> for a lot of confusion.

I agree, but I think locking up the other displays leads to even more
problems.  Having a debug window hidden on another display (or while
we are at it, on another frame) is confusing, but at least I can use
C-M-c or C-] to return to sanity from everywhere.  On the other hand,
having a whole display completely locked up with no indication of what
happened, and no way to unlock without switching to another display is
guaranteed to confuse and annoy me.

Here is an example: Let's say I log in to my office workstation from
home, and start up an Emacs display on my remote X server via
emacsclient.  Suppose that I was careless, and before I went home I
somehow left my Emacs inside a recursive edit.  In this case,
emacsclient will succeed to create a new frame on the remote server,
but the frame will not accept any input, not even a delete-frame event
from the window manager, until I go back to my office to press C-]. :-(

-- 
Károly