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
Eli Zaretskii <eliz <at> gnu.org> writes:
> 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.
Can you please submit a bug for this? I'm forgetting things.
> 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.
Not sure, but I think this could be explained by frame-visible-p of
other non-top root frames returning t.
This bug report was last modified 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.