Note that it might be relevant if high-resolution scrolling is supported or not. I'm only seeing this in a VNC environment that only has the classical "stepped" wheel events.

Thats related to this line:

File scrolls the same 3 lines you get in the scrollback buffer, or as commonly seen in almost all other terminals.

Which terminals show that behavior? (xterm does not on my system...)

As far as I can see with git blame, it has always been like that in the last 6 years.

That might very well be. I'm a new vscode user, so I'm comparing to other terminals, not to any previous xterm.js behaviour. :)

Which terminals show that behavior? (xterm does not on my system...)

Odd. I'm seeing it in xterm¹, GNOME terminal and MATE terminal (fork of GNOME 2 terminal). Tested on RHEL 9 and Fedora 40.

Three lines is also what xterm.js scrolls per click for me in the "normal" scrollback, so it's a bit confusing when the scroll distance changes when I open a less.

¹ xterm actually jumps 5 lines for me, not 3

Perhaps that sequence should be multiplied by the various settings affecting the scrollback, so they stay in sync?

I checked the xterm sources - thats basically linked there to alternateScroll or DECSET 1007. For some reason thats disabled on my system (ubuntu here).

Perhaps that sequence should be multiplied by the various settings affecting the scrollback, so they stay in sync?

I agree, we should strive to sync that with other scroll handling like on the normal scroll buffer.

So what we need here:

• implement a alternateScroll private toggling that scrolling on/off
• implement DECSET/DECRST 1007 on top
• put a default for it into terminal options
• sync scroll width with other scroll handling