[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys
From: |
Al Petrofsky |
Subject: |
bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys are hung |
Date: |
Mon, 12 Jun 2023 14:24:47 -0400 |
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.
- bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys are hung,
Al Petrofsky <=