Atypical "Erase In Display" behaviour

Most terminals seem to implement ED (specifically \x1b[2J) by not actually deleting anything from the display buffer, but rather by scrolling. Conversely, xterm.js does delete the display buffer’s contents, which is a) inconsistent and b) annoying because you lose output. I don’t think this behaviour qualifies as a bug because the spec doesn’t say about what should happen with the scrollback buffer, but would still be nice if this were changed.

Downstream issue in https://github.com/JunoLab/atom-julia-client/issues/521.

Details

• Browser and browser version: Electron 2.0.8
• OS version: Manjaro
• xterm.js version: master (but also at least 3.6 and 3.7)

Steps to reproduce

Try

for i in {1..20}; do
  echo "$i"
done
echo '\e[1;1H\e[2J'

in xterm.js and another terminal emulator, and scroll up afterwards.

Expected behaviour is what e.g. Konsole does (middle window), and not how e.g. VSCode (left) or Juno’s terminal (right, with xterm.js master) handles this.

[jerch]

Reading through the bugtracker comments in vte and konsole raises alot of questions regarding scrolling out, and make me think whether this is a good idea at all:

ED2 was never meant to do that, its purpose is to erase content on the active viewport in the sense of “clean that area”, nothing more. In fact apps might use it do full screen refreshs to start over drawing. I use it myself that way in several fullscreen scripts. Now if such an app does not switch to alternate buffer, it will dump every screen refresh into the scrollbuffer. The semantics are broken further by the fact, that ED1 does not add anything to the scrollbuffer. But why? By the spec description ED0 + ED1 should be equivalent to ED2, but it isnt anymore for scroll-out terminals. So semantically adding changes to the scrollbuffer for ED was a mistake, no clue who broke with the spec initially. Furthermore with SU (scroll up, CSI <rows> S) we already have an appropriate sequence for it. No need to water other sequences.

Now regarding whether this is common or not. I see that all OSX terminals I know do that, even Terminal.app. Under POSIX terminal emulators in general it is not that common - xterm (the father of all xterm-alikes and thus most common graphical TEs) doesnt do it, neither do the kernel consoles (tested linux and FreeBSD). The latter are more on the legacy side of things, but considering the semantic issues above, I am not so sure anymore if coupling scrollbuffer changes to ED2 was a great idea.

TL;DR After reading through the bugtracker and concerns listed there, I lean towards not implementing scrollout for ED2. It breaks horribly the sequence semantics and the basic unix principle “do one thing and do it right”. If ppl want scroll out, use the appropriate sequence for it (SU). All imho and up for discussion.

[pjlsergeant]

For many people, xterm.js will be the only terminal they use that doesn’t do it “properly”. Could this behaviour be behind a flag / OS check?