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

Lines don't appear in the scrollback when scroll region is enabled #3113

Closed
romkatv opened this issue Nov 20, 2020 · 5 comments
Closed

Lines don't appear in the scrollback when scroll region is enabled #3113

romkatv opened this issue Nov 20, 2020 · 5 comments
Labels

Comments

@romkatv
Copy link
Contributor

romkatv commented Nov 20, 2020

Describe the bug

When scroll region is set to [0, X] with X < height, the top lines don't appear in the scrollback after they disappear above the top screen boundary.

To Reproduce

  1. Start Kitty.
  2. Resize the window to 24 lines by 80 columns.
  3. Execute the following command:
printf '\033[H\033[J\033[3J\033[0;5r' && seq 100
  1. Observe the following (expected) content of the terminal window:
97
98
99
100
bash-5.0$ █
  1. Attempt to scroll the window with a mouse wheel to see the scrollback. There is nothing in there.

Expected behavior

The scrollback contains numbers 1-96, one per line.

Environment details

OS: Ubuntu 20.04

I've first noticed this when using Kitty from apt. Then I've reproduced it with Kitty built from the tip of master. Here's the output of kitty --debug-config:

kitty 0.19.2 (9193a20b44) created by Kovid Goyal
Linux adam-linux 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64
Ubuntu 20.04.1 LTS \n \l
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
Loaded config files: /etc/xdg/kitty/kitty.conf
Running under: X11

Config options different from defaults:
update_check_interval 0.0

Additional context

I'm not sure whether this is a bug. Independently, I'm not sure whether the current behavior is preferable. There are two reasons the current behavior of Kitty is surprising to me. The first is that it doesn't match the behavior of other terminals I've tested this on: GNOME Terminal, Konsole, XTerm, Rxvt and Apple Terminal. The only exception I've found is iTerm2 -- it behaves like Kitty.

Another reason is more pragmatic. It can be very confusing when some lines of the output get lost. Here's an example. apt package manager enables scroll region in order to display a nice progress bar at the bottom of the screen while logs scroll all above it. If I run sudo apt install -y konsole in a tall kitty window, here's what I see at the end.

bash-5.0$ sudo apt install -y konsole
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  lrzsz
The following NEW packages will be installed:
  konsole
0 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 750 kB of archives.
After this operation, 3967 kB of additional disk space will be used.
Get:1 http://ch.archive.ubuntu.com/ubuntu focal/universe amd64 konsole amd64 4:19.12.3-0ubuntu1 [750 kB]
Fetched 750 kB in 0s (3613 kB/s)
Selecting previously unselected package konsole.
(Reading database ... 206336 files and directories currently installed.)
Preparing to unpack .../konsole_4%3a19.12.3-0ubuntu1_amd64.deb ...
Unpacking konsole (4:19.12.3-0ubuntu1) ...
Setting up konsole (4:19.12.3-0ubuntu1) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu3) ...
bash-5.0$ █

Now, if I run the same command in a small window (6 lines by 80 columns) and resize it back to normal when the command finishes, here's what I see:

bash-5.0$ sudo apt install -y konsole
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  lrzsz
The following NEW packages will be installed:
  konsole
0 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 750 kB of archives.
After this operation, 3967 kB of additional disk space will be used.
Get:1 http://ch.archive.ubuntu.com/ubuntu focal/universe amd64 konsole amd64 4:19.12.3-0ubuntu1 [750 kB]
Fetched 750 kB in 0s (3028 kB/s)
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu3) ...
bash-5.0$

Note that 5 lines are missing. This is because after printing the "Fetched" line apt has decided to display a progress bar and enabled scroll region. Here's the code: https://github.com/Debian/apt/blob/master/apt-pkg/install-progress.cc.

I'm building something similar for zsh. Basically, I'd like the shell prompt line to stay at the bottom of the screen, visible at all times, sort of like a permanent status bar. Output of commands should go above the prompt line and shouldn't override it. To implement this, I'm enabling scroll region. I've noticed that on Kitty this effectively disables scrollback, which I would really like to avoid. Hence this issue. If there is a workaround I can employ, I'd be happy with that.

@romkatv romkatv added the bug label Nov 20, 2020
@kovidgoyal
Copy link
Owner

Well, it's not a bug, it's deliberate. Scroll regions don't have to be at the top of the screen, and its pretty weird if lines that disappear from the scroll region appear in the scrollback if they don't disappear from the top of the screen. However, I am not firmly wedded to this behavior.

How would you expect using scroll regions to work? there are many apps that expect to draw ont he full screen and define their own scroll regions and dont switch to the alternate screen. for instance less -X

@romkatv
Copy link
Contributor Author

romkatv commented Nov 20, 2020

Thanks for the speedy response. I expected that it's not a bug. None of the specs I've found seem to prescribe what should happen.

My expectation is based on popular Linux terminals: GNOME Terminal, Konsole, XTerm and Rxvt. They handle scroll region like Kitty except when the region starts from the very top. In the latter case lines that disappear from the screen appear in the scrollback. This special-casing requires extra code, so it's unlikely to have happened by accident. Apple Terminal also does this, which reinforces the hypothesis of this behavior being intentional and therefore desirable.

It does mean that less -X fills scrollback, which is definitely not desirable. However, extra junk in scrollback seems preferable over missing lines like in the case of apt.

@kovidgoyal
Copy link
Owner

Well, making an exception for when the scroll region is at the top might be worthwhile. I will accept a patch for it, if it makes your life easier. The relevant line is 1002 in screen.c. Please also add a test for it in kitty_tests/screen.py

If you dont wish to then I will get to it when I have some time.

@romkatv
Copy link
Contributor Author

romkatv commented Nov 20, 2020

Well, making an exception for when the scroll region is at the top might be worthwhile. I will accept a patch for it, if it makes your life easier. The relevant line is 1002 in screen.c. Please also add a test for it in kitty_tests/screen.py

Thanks for pointing the exact line that needs to be changed! I've sent you #3114.

I've added 3 tests that verify the behavior when there is only the top margin, only the bottom, and both. I expected that in all cases lines won't be appended to the scrollback. It turns out that if there is only the top margin, then lines do get appended to the scrollback. You can see it by running this command in a window that's 24 lines tall:

printf '\033[H\033[J\033[3J\033[2;24r' && seq 100

The screen will contain the numbers 1 and 79-100. The scrollback will contain the rest.

I've change this case to not append lines to the scrollback. So, out of the 3 tests I've added, only test_top_and_bottom_margin passes prior to the PR.

@romkatv
Copy link
Contributor Author

romkatv commented Nov 20, 2020

That was fast! Thanks.

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