GNU bug report logs - #64025
28.2; when minibuffer active, all other X11 displays and ttys are hung

Previous Next

Full log

Message #8 received at 64025 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Al Petrofsky <al <at> petrofsky.org>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, Richard Stallman <rms <at> gnu.org>,
 64025 <at> debbugs.gnu.org
Subject: Re: bug#64025: 28.2; when minibuffer active, all other X11 displays
 and ttys are hung
Date: Tue, 13 Jun 2023 08:34:45 +0800

Al Petrofsky <al <at> 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''?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.