GNU bug report logs - #75854
31.0.50; Cursor positioning with multiple TTY frames

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sun, 26 Jan 2025 10:11:01 UTC

Severity: normal

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75854 in the body.
You can then email your comments to 75854 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#75854; Package emacs. (Sun, 26 Jan 2025 10:11:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eli Zaretskii <eliz <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 26 Jan 2025 10:11:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Cursor positioning with multiple TTY frames
Date: Sun, 26 Jan 2025 12:10:33 +0200
To reproduce:

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

(Note: the build details below do not mean this problem is specific to
the MS-Windows build, I see this on GNU/Linux.)

In GNU Emacs 31.0.50 (build 530, i686-pc-mingw32) of 2025-01-26 built on
 ELIZ-PC
Repository revision: 35d39278599caf30eb4bfbd83118ffe15d2bc705
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.22631
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4751)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --without-native-compilation --enable-checking=yes,glyphs 'CFLAGS=-O0
 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
tty-child-frames emacs)

Memory information:
((conses 16 45585 18821) (symbols 48 6532 0) (strings 16 16140 2697)
 (string-bytes 1 333074) (vectors 16 9411)
 (vector-slots 8 111027 7616) (floats 8 23 6) (intervals 40 305 110)
 (buffers 896 10))




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Thu, 30 Jan 2025 12:10:01 GMT) Full text and rfc822 format available.

Notification sent to Eli Zaretskii <eliz <at> gnu.org>:
bug acknowledged by developer. (Thu, 30 Jan 2025 12:10:01 GMT) Full text and rfc822 format available.

Message #10 received at 75854-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75854-done <at> debbugs.gnu.org
Subject: Re: bug#75854: 31.0.50; Cursor positioning with multiple TTY frames
Date: Thu, 30 Jan 2025 14:08:50 +0200
> Date: Sun, 26 Jan 2025 12:10:33 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> To reproduce:
> 
>   $ 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.

These problems are now fixed on the master branch, probably as result
of the recent changes related to TTY frames.  So I'm closing this bug.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 27 Feb 2025 12:24:13 GMT) Full text and rfc822 format available.

This bug report was last modified 14 days ago.

Previous Next


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