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