Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kitty shuffles lines randomly in scrolling windows #7052

Closed
lindy2076 opened this issue Jan 24, 2024 · 8 comments
Closed

Kitty shuffles lines randomly in scrolling windows #7052

lindy2076 opened this issue Jan 24, 2024 · 8 comments
Labels

Comments

@lindy2076
Copy link

lindy2076 commented Jan 24, 2024

Describe the bug
When I use glow to view Markdown files or fzf with preview window I have problems with kitty rendering lines after scrolling.

I thought it was glow's issue but after installing fzf i encountered it again.
I wrote an issue charmbracelet/glow#554 where I described how to reproduce this bug.
My guess is that kitty has problems rendering scrolling windows with some static window (glow has a small line of text in the bottom and fzf has a preview window on top).
I use glow only in pager mode now (glow -p) because it doesn't produce "ghost" lines and don't shuffle them (it uses less).
Also I was noticing "ghost" lines after exiting vim sometimes. My prompt showed the previous command vim *filename* but it was not real (it was replaced by the next command like if i had activated the insert mode in a text editor).

To Reproduce
Steps to reproduce the behavior:

  1. Install glow or fzf
  2. Open long enough file and scroll fast.
  3. See lines being shuffled randomly and ghost text.

Screenshots

glow

The original file is on the right. It is clear that glow messed some lines in the last paragraph (on the left):
Screenshot from 2024-01-08 00-16-44

But after going to the bottom by pressing G everything aligns normally (that's how the file on the right was opened)

fzf (large input, e.g. rg --files)

After some scrolling lines became messed up
Screenshot from 2024-01-24 15-52-06

But after reopening the preview window on top everything became normal.
Screenshot from 2024-01-24 15-54-29

exiting vim

Lines messed up. The cursor is on penultimate line (one line from the bottom)
Screenshot from 2024-01-24 16-08-25
Screenshot from 2024-01-24 16-08-41

Environment details

kitty 0.32.0 (eb5dd364ae) created by Kovid Goyal
Linux lindy-nb 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64
Ubuntu 22.04.3 LTS lindy-nb /dev/tty

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
Running under: X11
Frozen: True
Paths:
  kitty: /home/lindy/.local/kitty.app/bin/kitty
  base dir: /home/lindy/.local/kitty.app/lib/kitty
  extensions dir: /home/lindy/.local/kitty.app/lib/kitty-extensions
  system shell: /bin/bash
Loaded config files:
  /home/lindy/.config/kitty/kitty.conf

Config options different from defaults:
background_opacity   0.9
font_family          FiraCode Regular
window_padding_width FloatEdges(left=5.0, top=5.0, right=5.0, bottom=5.0)
Changed shortcuts:
	kitty_mod+n →  new_os_window, new_os_window_with_cwd
Colors:
	background           #2a3234   
	color0               #222627   
	color1               #ff6188   
	color10              #a9dc76   
	color11              #e9cb8b   
	color12              #fc9867   
	color13              #fa75c3   
	color14              #78dce8   
	color15              #fcfcfa   
	color2               #c5d157   
	color3               #e9cb8b   
	color4               #c79275   
	color5               #ad99dd   
	color6               #b7ebff   
	color7               #2a3234   
	color8               #6b8d89   
	color9               #f97683   
	cursor               #fcfcfa   
	cursor_text_color    #222627   
	foreground           #fcfcfa   
	selection_background #fcfcfa   
	selection_foreground #f98d9a   

Important environment variables seen by the kitty process:
	PATH                                /home/lindy/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/go/bin
	LANG                                en_US.UTF-8
	EDITOR                              vim
	SHELL                               /bin/bash
	DISPLAY                             :0
	USER                                lindy
	LC_TIME                             ru_RU.UTF-8
	XDG_SEAT                            seat0
	XDG_SESSION_TYPE                    tty
	LC_MONETARY                         ru_RU.UTF-8
	XDG_SESSION_CLASS                   user
	XDG_SESSION_ID                      1
	LC_ADDRESS                          ru_RU.UTF-8
	XDG_RUNTIME_DIR                     /run/user/1000
	LC_TELEPHONE                        ru_RU.UTF-8
	LC_NAME                             ru_RU.UTF-8
	LC_MEASUREMENT                      ru_RU.UTF-8
	LC_IDENTIFICATION                   ru_RU.UTF-8
	XDG_VTNR                            1
	XDG_DATA_DIRS                       /usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
	LC_NUMERIC                          ru_RU.UTF-8
	LC_PAPER                            ru_RU.UTF-8

Additional context
Starting kitty with --config=none doesn't help, the problem is still present

@lindy2076 lindy2076 added the bug label Jan 24, 2024
@kovidgoyal
Copy link
Owner

kitty will render whatever the program running in it asks it to render.
If you think there is some bug in how kitty renders thing come up with a
reproducer that doesn't involve tons of other software. Chances are that
software is simply doing something wrong, not following kitty's terminfo
or using incorrect width calculations for unicode characters are the
most common things software get wrong.

You can easily generate a reproducer by running kitty with --dump-bytes
and doing the minimal amount of work to produce incorrect rendering.
Then post the log generated by --dump-bytes alongwith the terminal size
in cells in which it was generated.

When you do, I will take a look at it, but as I said chances are it is
the client software not producing appropriate output. If the log is too
large then analysing it will be too much work, and you will need to come
up with a simpler reproducer.

@lindy2076
Copy link
Author

Here it is, starting glow, switching the tab, selecting lorem ipsum md, scrolling till the end and then pressing G button to make lines look normally
(288 lines)
tput cols and tput lines output: 98 55

kitty_dump_bytes.gz

@kovidgoyal
Copy link
Owner

I need the log only till whatever point the render was corrupted. Simply
close kitty at that point dont press G.

@lindy2076
Copy link
Author

Same but closing after scrolling down
kitty_dump2.gz

@kovidgoyal
Copy link
Owner

OK I'll look at it when I have some time

@lindy2076
Copy link
Author

lindy2076 commented Jan 24, 2024

I managed to make it even shorter. So i just run rg --files | fzf --preview="xdg_prog {}" --bind="ctrl-space:toggle-preview" --preview-window=up,15% and scroll up a little.

xdg_prog is a bash script that echoes two lines:

MIME=$(xdg-mime query filetype "$1")
TOOL=$(xdg-mime query default $MIME)
echo -e "Opener: $TOOL\nmime: $MIME"

kitty-dump-fzf1234.gz

P.S.
I tried to start only kitty with startx kitty and the bug was present

@kovidgoyal
Copy link
Owner

Dumping those bytes in xterm gives the exact same broken rendering, see attached screenshot. So not a kitty bug.
screenshot

@lindy2076
Copy link
Author

Yeah, indeed. I have this problem in gnome-terminal too... Thanks for help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants