Re: Emacs routinely gets stuck in single_kboard mode

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

Sorry for the long response time!

Richard Stallman <rms@gnu.org> writes:
>     A possible third bug (and a definite inconvenience) is that entering a
>     recursive edit (M-x recursive-edit) or a debug session like above sets
>     single_kboard.  Pressing C-g unfreezes the other keyboards without
>     exiting the recursion, with no apparent bad side effects.  The bug is
>     either that the displays are frozen unnecessarily, or that C-g should
>     not break out of single_kboard in this case.
>
> 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.  I
have only seen exactly these same effects when C-g exited
single_kboard, no new bugs.  So why are multiple displays different
from frames in this particular case?  Did I miss some important edge
case in the implementation?  Input event processing in Emacs is still
a hazy area for me.

By the way, the biggest such inconvenience I have found is a small
wrinkle that appears when I forget about a minibuffer prompt and
switch to another frame.  It is reproducible in the CVS trunk, too:

    emacs -q --eval '(setq enable-recursive-minibuffers t)'
    	C-x 5 2
        <First frame> C-x C-f
        <Second frame> M-x
        	(Note that the cursor in the first frame returns to
                 the *scratch* buffer's window)
        <Second frame> C-g

At this point, the C-x C-f prompt is still there in the minibuffer,
but the minibuffer window is active in neither frame.  What is more,
pressing C-x o to return to the minibuffer to finish (or cancel) the
command only works in the second frame, not in the first where it was
initiated.  (I seem to remember that Emacs 19/20 behaved more
intuitively, but I am not able to test that now.)

> This is part of the reason why we discourage use of recursive edit.
> It cannot be avoided unless we implement multi-threading in Emacs.
>
> Does this fix that bug?

Yes, the patch does prevent C-g from unfreezing the other displays.

> *** keyboard.c	11 Jun 2004 21:54:28 -0400	1.778
> --- keyboard.c	13 Jun 2004 16:19:43 -0400	
> ***************
> *** 1158,1164 ****
>   
>     Vinhibit_quit = Qnil;
>   #ifdef MULTI_KBOARD
> !   any_kboard_state ();
>   #endif
>   
>     return make_number (0);
> --- 1158,1165 ----
>   
>     Vinhibit_quit = Qnil;
>   #ifdef MULTI_KBOARD
> !   if (command_loop_level == 0 && minibuf_level == 0)
> !     any_kboard_state ();
>   #endif
>   
>     return make_number (0);

-- 
Károly