SUMMARY When scrolling up multiple lines (currently only done by an escape sequence) only one line is saved to the history buffer, the rest are lost. STEPS TO REPRODUCE 1. Run in konsole: seq 1 100 echo -e "\e[20S" 2. Scroll back half a page OBSERVED RESULT 19 lines are missing (for a terminal of 40 lines, the numbers jump from 63 to 83). EXPECTED RESULT All lines are displayed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2
Info on other terminal emulators. There are several cases to consider: - No margins - Vertical margin that includes line 1, e.g. 1;$((LINES-2)) - Vertical margin that doesn't include line 1, e..g 2;$((LINES)) - Horizontal margins xterm, urxvt and wezterm move lines into the scrollback buffer for the 2 first cases, but not for the last 2 (urxvt actually doesn't support horizontal margins). vte doesn't move lines into the scrollback buffer for any case, and so behaves like konsole. mlterm moves lines into the scrollback buffer for the first 3 cases, but not for the last 1. contour moves lines into the scrollback buffer for the first case, but not for the last 3 (it actually crashes on the horizontal margins case). An argument can be made that SU (Scroll-Up/Pan-Down: CSI Ps S) is typically used by fullscreen applications like vim, and it doesn't make sense to move lines into the scrollback buffer in that case. Do you have a real-world use case for this?
(In reply to ninjalj from comment #1) > Info on other terminal emulators. > > There are several cases to consider: > - No margins > - Vertical margin that includes line 1, e.g. 1;$((LINES-2)) > - Vertical margin that doesn't include line 1, e..g 2;$((LINES)) > - Horizontal margins > > xterm, urxvt and wezterm move lines into the scrollback buffer for the 2 > first cases, but not for the last 2 (urxvt actually doesn't support > horizontal margins). This is the behavior I expect, and see as most consistent. When a line is scrolled from the top of the screen it is added to history. I don't see why scrolling using CSI S should be an exception. > vte doesn't move lines into the scrollback buffer for any case, and so > behaves like konsole. vte is a bit more consistent than konsole - it does not save any lines to the history when using the CSI S escape sequence. konsole saves one line to history regardless of how many lines are scrolled. This is the least consistent of all > mlterm moves lines into the scrollback buffer for the first 3 cases, but not > for the last 1. > contour moves lines into the scrollback buffer for the first case, but not > for the last 3 (it actually crashes on the horizontal margins case). > > An argument can be made that SU (Scroll-Up/Pan-Down: CSI Ps S) is typically > used by fullscreen applications like vim, and it doesn't make sense to move > lines into the scrollback buffer in that case. fullscreen applications run in the alternate screen buffer mode, so do not have a scrollback buffer at all. > Do you have a real-world use case for this? Indeed, there is no much use for scrolling multiple lines in text programs. I found this surprising behavior while working on adding graphics support for the terminal. A picture is added to the screen all at once which might require scrolling multiple lines at once. This is unlike text which is usually added line by line, so does not need to scroll more than one line at a time.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/591