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

Previous Next

Full log

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

From: Al Petrofsky <al <at> petrofsky.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; when minibuffer active, all other X11 displays and ttys are hung
Date: Mon, 12 Jun 2023 14:24:47 -0400

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Previous Next

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