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

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

[Al Petrofsky]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1542 bytes --]

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Al Petrofsky <al@petrofsky.org> writes:

> 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.

This is a known problem of the multi-tty code.

** The single-keyboard mode of MULTI_KBOARD is extremely confusing
   sometimes; Emacs does not respond to stimuli from other keyboards.
   At least a beep or a message would be important, if the single-mode
   is still required to prevent interference.  (Reported by Dan
   Nicolaescu.)

   Update: selecting a region with the mouse enables single_kboard
   under X.  This is very confusing.

   Update: After discussions with Richard Stallman, this will be
   resolved by having locked displays warn the user to wait, and
   introducing a complex protocol to remotely bail out of
   single-kboard mode by pressing C-g.

   Update: Warning the user is not trivial to implement, as Emacs has
   only one echo area, shared by all frames.  Ideally the warning
   should not be displayed on the display that is locking the others.
   Perhaps the high probability of user confusion caused by
   single_kboard mode deserves a special case in the display code.
   Alternatively, it might be good enough to signal single_kboard mode
   by changing the modelines or some other frame-local display element
   on the locked out displays.

   Update: In fact struct kboard does have an echo_string slot.

Dan, Richard, whatever became of this ``complex protocol to remotely
exit single-kboard mode''?