Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Emacs has support for multiple X displays, each with their own
keyboard.  (The multi-tty branch uses the same mechanism to support
more than one tty device.)  To prevent interference from another
keyboard, Emacs sets single_kboard while reading from the minibuffer
or executing an interactive command.  When that variable is set, input
from other keyboards is stacked away unprocessed until it is reset to
zero.  Unfortunately, in some cases Emacs fails to clear
single_kboard, which causes problems.  For example, try the following
commands on a system that supports X forwarding via local ssh
connections:

        $ ssh -X localhost      # Create an alias for the current display
        Password: ******
          $ echo $DISPLAY
          localhost:10
          $

        Then, from another terminal:

        $ emacs -q --no-site-file -f ignore     # Note the -f parameter!
        M-x make-frame-on-display <RET> localhost:10 <RET>

make-frame-on-display should succeed creating a new frame on the
forwarded X connection, but the new frame does not accept input; not
even C-g.  (Make sure you don't press C-g in the first frame, because
it unconditionally resets single_kboard and thus unfreezes the other
frame.)  The bug is triggered by specifying an interactive command to
be executed by the -f option.

But this is not the only time Emacs gets stuck in single_kboard mode.
Here is another (more frequent) case:

        $ emacs -q --no-site-file
        M-x make-frame-on-display <RET> localhost:10 <RET>
        slartibartfast C-x C-e    # void-variable error

        ==> The other frame is locked up, which might be
            intentional.  But exiting the debugger by
            pressing q does not help, which is certainly a bug.

(Pressing C-g on the single unlocked display always returns things to
normal, but finding that display is not always easy.)

Multi-tty users stumble upon these bugs quite frequently (e.g. `emacs
-f server-start' is a popular alias).  I attached a patch (adapted
from emacs--multi-tty--0--patch-189) that clears single_kboard each
time Emacs returns to top-level.  This seems to fix both bugs:

*** orig/src/keyboard.c
--- mod/src/keyboard.c
***************
*** 1247,1252 ****
--- 1247,1256 ----
      while (1)
        {
        internal_catch (Qtop_level, top_level_1, Qnil);
+         /* Reset single_kboard in case top-level set it while
+            evaluating an -f option, or we are stuck there for some
+            other reason. */
+         any_kboard_state ();
        internal_catch (Qtop_level, command_loop_2, Qnil);
        executing_macro = Qnil;
  

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.  (I hope the former, but
verifying (or fixing) this is hard for me.) :-)

(By the way, sometimes single_kboard is very annoying even when it
works right: accidentally leaving an active minibuffer on one display
freezes all others, with no way to awaken them without access to the
display that caused the lockup.  It would be nice if Emacs could
always accept input from each keyboard.  But if that's not possible, I
think it should at least provide some feedback when the user presses a
key on the "wrong" display, and maybe allow C-g to work on frozen
displays. WDYT?)

-- 
Károly