bug-gnu-emacs
[Top][All Lists]
Advanced

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]