Misplaced cmdline after terminal resize

[jrmd54]

Describe the bug
The bug occurs when the terminal has been resized while an application is open in it (for example, nano or vim).
Exiting the application will cause the cmdline to appear in the middle of previously typed commands, instead of starting after the last command.

To Reproduce
These steps were reproduced without a .bashrc and with the default gnome desktop manager.

kitty -c NONE
# Fill the screen with text to be able to reproduce issue, open text file with nano
cat /usr/bin/ls && nano /usr/bin/ls
# Shrink size of term (only by width), exit nano with ctrl-x
# The current cmdline is overlapping the previous command and overwriting it

Bug reproduction may be affected by initial size of the terminal.
Sometimes the cmdline is not just misplaced on the previous command, but in the middle of the screen.

Video
https://github.com/user-attachments/assets/a1c95a2d-e219-43d5-b987-83fdc3382703

Environment details

kitty 0.36.4 (c127517c96) created by Kovid Goyal
Linux jrmd54-XPS-15-9520 6.5.0-44-generic #44-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun  7 15:10:09 UTC 2024 x86_64
Ubuntu 23.10 jrmd54-XPS-15-9520 /dev/tty

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=23.10
DISTRIB_CODENAME=mantic
DISTRIB_DESCRIPTION="Ubuntu 23.10"
Running under: X11
OpenGL: '4.6 (Core Profile) Mesa 23.2.1-1ubuntu3.1' Detected version: 4.6
Frozen: True
Fonts:
  medium: DejaVuSansMono: /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf:0
          Features: ()
    bold: DejaVuSansMono-Bold: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf:0
          Features: ()
  italic: DejaVuSansMono-Oblique: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Oblique.ttf:0
          Features: ()
      bi: DejaVuSansMono-BoldOblique: /usr/share/fonts/truetype/dejavu/DejaVuSansMono-BoldOblique.ttf:0
          Features: ()
Paths:
  kitty: /home/jrmd54/.local/kitty.app/bin/kitty
  base dir: /home/jrmd54/.local/kitty.app/lib/kitty
  extensions dir: /home/jrmd54/.local/kitty.app/lib/kitty-extensions
  system shell: /bin/bash

Config options different from defaults:

Important environment variables seen by the kitty process:
	PATH                                /home/jrmd54/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
	LANG                                en_US.UTF-8
	SHELL                               /bin/bash
	DISPLAY                             :1
	USER                                jrmd54
	XDG_CONFIG_DIRS                     /etc/xdg/xdg-ubuntu:/etc/xdg
	XDG_MENU_PREFIX                     gnome-
	LC_ADDRESS                          fr_FR.UTF-8
	LC_NAME                             fr_FR.UTF-8
	LC_MONETARY                         fr_FR.UTF-8
	XDG_SESSION_DESKTOP                 ubuntu
	XDG_SESSION_TYPE                    x11
	LC_PAPER                            fr_FR.UTF-8
	XDG_CURRENT_DESKTOP                 ubuntu:GNOME
	XDG_SESSION_CLASS                   user
	LC_IDENTIFICATION                   fr_FR.UTF-8
	LC_TELEPHONE                        fr_FR.UTF-8
	LC_MEASUREMENT                      fr_FR.UTF-8
	XDG_RUNTIME_DIR                     /run/user/1000
	LC_TIME                             fr_FR.UTF-8
	XDG_DATA_DIRS                       /usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
	LC_NUMERIC                          fr_FR.UTF-8

Additional context
Command lines that are overwritten when this bug occurs are also overwritten in the scrollback.

[kovidgoyal]

Your reproduction involves catting binary data into the tty never do that, it leads to undefined behavior. Use cat -v and I doubt nano can edit binaries safely either use hexdump for it. If you have a reproduction that doesnt involve undefined behavior feel free to update.

[jrmd54]

I used output of /usr/bin/ls because it allows the bug to be reproduced on any machine, but it works with any text.

The bug can be reproduced by using the command

man ls | col -b

instead of

cat /usr/bin/ls

[kovidgoyal]

Does not reproduce for me with either catting ls or the output of ls.

[kovidgoyal]

If I had to guess I would assume the version of nano on your system (which I see is Ubuntu) is old/buggy.

[jrmd54]

Hello,

I was able to reproduce the bug on a freshly installed vm (with latest ubuntu version 24.04.1).
I did not modify the base ubuntu install except by installing the curl package and kitty (as shown in the history command result in the video).

kitty_bug_reproduce_v2.mp4

As seen in the video, multiple trials can be needed to reproduce the bug.
(without using cat on a binary file this time)

It seems that any program embedding their ui in the terminal is able to reproduce the bug (i reproduced it with vim, nano, ranger, etc...)

I tried to reproduce this issue on other terminals (gnome and alacritty) without success, so i would say it is somehow related to kitty.

[kovidgoyal]

Ah, I know what your issue is. bash or more precisely readline on your
system is not clearing to end of line when redrawing the prompt. Use zsh
instead of bash and you wont have this issue or simply add \033[2K to
the start of your bash prompt aka PS1

[jrmd54]

I found out the correct behavior that reproduce the issue:

1 - In the kitty terminal, run a command that prints at least 1 line (*)
2 - run again that command N times
3 - open nano/vim
4 - resize the terminal so that its new width is now narrower that at least one of the lines outputted by the command
5 - exit nano/vim

There are now 2 possible results:
a - If the last line of the terminal was not reached when executing the commands:
The command line will now be misaligned by the number of lines from the previous commands that were cut due to the new shorter size. (scenario recorded in the new video)
b - the cmdline is at the bottom but is overwriting the last command instead of creating a new cmdline (video of previous post)

Video displaying result 'a'
https://github.com/user-attachments/assets/09b2f939-79dc-4cf8-9631-61338930e9d3

I tried the fix you proposed but:
case a: the command line is still misaligned (but the line is empty)
case b: the line is empty but the last command is erased from the scrollback

I think a possible to fix case 'a' would be to realign the cmdline by shifting it by the same number of carriage return that were added to the scrollback by cutting its lines due to the shorter terminal size.
(case 'b' must be related but i don't see exactly what may be the fix)

(*) bug is reproducible even if there is no output, new term size just has to be narrower than the cmdline