Avoid using CSI S sequence for scroll down

[st0012]

After reading PowerShell/PSReadLine#724, I suspected that the use of CSI S sequence for scroll down is also the cause of #576. So I swapped it with just writing \n (inspired by PowerShell/PSReadLine#790), and it seems to work.

However, I couldn't find further information on how using the CSI S sequence would cause the problem and why it only happens in VS Code terminal. So I'm not sure if this is the best fix for the problem.

This seems to fix #576

[st0012]

I couldn't find further information on how using the CSI S sequence would cause the problem and why it only happens in VS Code terminal

@tompng Do you know anything about these?

[tompng]

I think this fix is good 👍

CSI+S and \n

CSI+S and \n have some difference.
CSI+S: always scroll down
\n: scroll down only when cursor is at the bottom of the scroll range

Fortunately, LineEditor always moves cursor to the bottom before calling IOGate.scroll_down.

reline/lib/reline/line_editor.rb

Lines 353 to 354 in 46db711

	Reline::IOGate.move_cursor_down(@rest_height)
	Reline::IOGate.scroll_down(val - @rest_height)

The meaning of the method is a bit changed, but I think adding a comment (limitation that ANSI.scroll_down only works when cursor is at the bottom) is enough.

Why it only happens in VS Code terminal

ANSI escape sequence has scroll-range setting.

If you run this code

# Before running this code, clear the screen with ctrl + l or command + k
use_csi_s = true # or false
scroll_range = 3..8 # or 1..8
print "\e[H" # move cursor to first row of the screen
print "\e[J" # clear screen
(1..10).each { |y| puts y }
print "\e[#{scroll_range.begin};#{scroll_range.end}r" # set scroll range
if use_csi_s
  print "\e[3S" # scroll down 3 rows using CSI+S
else
  print "\e[8H\n\n\n" # \n at the bottom of scroll range will also scroll down
end
print "\e[r" # rest scroll range
print "\e[11H" # move cursor to row 11

You will get this.

1
2
6 # ← scroll range start
7 #
8 #
  #
  #
  # ← scroll range end
9
10

The difference happens when scroll range is set to 1..y. (default is 1..screen_height)
VS Code terminal seems to be doing:

• Scrolling with \n acts like scroll range is set to -infinity..y
• Scrolling with CSI+S acts like scroll range is set to 1..y

Other terminal emulators(Terminal, iTerm, Alacritty) seems to be doing:

• Acts like scroll range is set to -infinity..y in both \n and CSI+S

I don't know which behavior is correct. (I like VSCode's behavior)

[st0012]

Thanks for the explanation!

You will get this.

I did get the result. But should it be different depending on use_csi_s's value? I don't seem to see a difference from changing it. I also didn't get different result between VS Code Terminal and iTerm2.

[tompng]

Sorry I forgot to write this.
With use_csi_s = true and scroll_range = 1..8, the screen will be the below in all terminal

4
5
6
7
8



9
10

But the difference is in the scroll buffer.
VS Code terminal: scroll buffer is empty.
Other: There is 1\n2\n3 hidden in the scroll buffer.

[tompng]

Little good difference
Left: using CSI+S, Right: using "\n"
Scenario: move cursor to bottom, clear screen with command K, then input multiline code.

csi_s.mp4

When you clear the screen using command K instead of \C-l in Terminal.app, Reline can't know when the screen is cleared, (there is no input sequence for command K) and screen might corrupt. This is same for Emacs, Vim, and other CUI applications.
But after this fix, corruption looks gone (or improved).