bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys are hung

[Al Petrofsky]

If you have emacs connected to more than one "terminal" (X11 server or
tty), you can walk back and forth between the terminals entering
commands.  But if you neglect to finish a command and leave the
terminal while the minibuffer is active, then when you get to the
other terminal room, emacs is completely unresponsive.

   emacs -Q --daemon=test
   [on tty1:] emacsclient -t --socket-name=test
   [on tty2:] emacsclient -t --socket-name=test
   [on tty1:] M-x
   [on tty2:] C-g C-g C-] C-g ... [nothing happens]

This seems to be the case regardless of whether the terminals are
graphical or ttys, and regardless of whether created by emacsclient or
make-frame-on-display.

This can be seen as a feature request more than a bug report, but it's
at least a documentation bug that the Multiple Displays info node
makes no mention of the limitation.

Ideally, when the minibuffer is active on one terminal and a keystroke
is received on another, the miniwindow would move to or be duplicated
on the other terminal.  At a minimum, it should be possible to get
emacs to abort to top-level by typing some combination of C-g or C-]
at any terminal.

A related situation that doesn't involve the minibuffer is:

   [on tty1:] (while t t) C-x C-e
   [on tty2:] C-g C-g C-] C-g ... [nothing happens]

Some way of reliably aborting to top-level from any terminal would
mostly fix both problems.