GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Sun, 26 Jan 2025 11:00:41 +0200

> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 10:11:50 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Cc: lenbok <at> gmail.com,  75056 <at> debbugs.gnu.org
> > Date: Sun, 26 Jan 2025 08:50:14 +0100
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > What happens in this case is that F2 cannot be communicated with:
> > > typing anything there gets no response, until we exit the minibuffer
> > > on F1.  Then everything you typed on F2 gets processed.
> > >
> > >> Find in the code what actually happens when switching from F1 to F2 and
> > >> compare that with admin/notes/multi-tty has to say about that. Does that
> > >> document say something about what we've seen the code doing? Open issues
> > >> maybe? Or general considerations?
> > >
> > > What the code does when Emacs enters a minibuffer is switch to a
> > > "single-keyboard mode", whereby it only processes keyboard input from
> > > the frame which entered the minibuffer.  This is because Emacs has
> > > only one input queue.
> > 
> > I would perhaps check how that switching to single-kboard is done. That
> > is, which C functions do that, what does do_switch_frame do and so on.
> 
> See temporarily_switch_to_single_kboard in keyboard.c.

Btw, when I do that on the current master branch, I see some
unexplained cursor movements.  Recipe:

  $ emacs -Q -nw
  M-x server-start RET

Now on another TTY display:

  $ ./lib/src/emacsclient -t ./src/dispnew.c

Now observe how the cursor on the first display (where we started
"emacs -Q -nw") is positioned at the left edge of the mode line,
instead of keeping its previous position.

Now switch back to the fist TTY display and press some key.  The
cursor is moved to its correct position, but now the cursor on the
second TTY display is a the beginning of the mini-window!

Now switch to the second TTY display and press down-arrow: the cursor
on that display is now correct, but the cursor on the first display is
now at the beginning of the mini-window.

Here's another problem with cursor movement, which doesn't involve
multy-tty at all:

  $ emacs -Q -nw
  C-x 5 b RET
  M-: (frame-visible-p (next-frame))

After typing the last line above into the minibuffer, don't press RET.
Instead, move the cursor left one character with C-b and type "C-x
C-e".  This should evaluate the (next-frame) part and show the result
in the echo-area.  But note that, while showing the result of the
evaluation, the cursor is not at the end of the value returned by
next-frame, but several places to the right, after some empty space.
This doesn't happen in Emacs 30.

Previous Next

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