xterm.js
xterm.js copied to clipboard
xtermjs
implement alternateScroll settings
Details
- VScode version: 1.93.1
- OS version: RHEL 9
Steps to reproduce
less file.txt- Scroll mouse one click
Expected outcome
File scrolls the same 3 lines you get in the scrollback buffer, or as commonly seen in almost all other terminals.
Actual outcome
File scrolls a single line.
Additional details
If I do an strace of less, I can see the other terminals send three \33OB on one mouse scroll click, whilst xterm.js only sends the one. Which fully explains things.
I couldn't find any setting in vscode that affected this. Workarounds are welcome.
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: https://github.com/xtermjs/xterm.js/blob/f701d073d15f7b312a9d051e719f748665701cef/src/browser/CoreBrowserTerminal.ts#L813 As far as I can see with git blame, it has always been like that in the last 6 years.
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