Alternate screen shouldn't write to scrollback or normal screen

[egmontkob]

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.6.2951.0

Epic

Scrollback handling should be just like in VTE because that's the best (ahem ahem) 🤣

Steps to reproduce 1

• ssh to a Linux box, and execute these:

  seq -f 'normal %.f' 100
  echo -ne '\e[?1049h' # switch to alt screen
  seq -f 'alt %.f' 100
  echo -ne '\e[?1049l' # switch back to normal screen
  

• scroll back and examine the contents

Expected behavior 1

Outputs of these two seqs shouldn't interleave

Actual behavior 1

Output consists of normal 1 to normal 74 (exact number depends on the window height), followed by alt 1 to alt 74, and finally normal 75 to normal 100. (alt 75 onwards are gone.)

Steps to reproduce 2

• ssh to a Linux box.
• produce a few pages of output
• start a fullscreen app such as mc
• resize the window in various ways (maybe even back and forth to smaller and then bigger)
• quit mc
• examine the output, including the scrollback

Expected behavior 2

This should look okay (see below).

Actual behavior 2

The contents seem quite garbled. Most of the time you'll see remains of mc's user interface in the scrollback buffer; sometimes even on the normal screen (this latter is harder to reproduce, and perhaps only happens with solid background colors).

---

VTE rocks

The way this works amazingly in gnome-terminal is:

The alternate screen is pretty much only used by fullscreen apps that control the entire UI and repaint on window resize. Therefore it's unrelated to the normal screen and the scrollback. Data never travels between the (normal screen + scrollback) combo and the alternate screen. The scrollback buffer belongs to the normal screen only. Everything scrolled out from the alternate screen is lost for good.

On resize, the (normal screen + scrollback) is resized as a single unit, for the resizing operation it doesn't matter where the boundary is.

The (normal screen + scrollback) combo is resized the same way, regardless of whether it's the active one or the alternate screen is shown. Stress-test this: produce output on the normal screen, switch to the alternate one (e.g. mc), resize, quit mc. The normal screen's contents will be updated to the new width just as if you haven't switched to the alternate screen.

There's plenty of further tiny details to this story, e.g. how to vertically position the contents, some of which are documented in VTE's doc/rewrap.txt.

Of course there's no specification anywhere that all this has to behave like this. It's just what I believe makes the most sense. Obviously my opinion is quite biased since this was my first big contribution to VTE. :) Luckily I only had to do the rewrapping; the separation of the (normal screen + scrollback) vs. alternate screen was already as desired.

[DHowett-MSFT]

This is actually one of the unfortunate circumstances of the pseudoconsole API.

conhost implements the alt buffer reasonably well (we think): it turns off scrollback, reflow, and so on.
When it remotes the contents of the screen as VT over pseudoconsole we're not also sending the alt buffer state down the wire (#381).

[ghost]

🎉This issue was addressed in #12561, which has now been successfully released as Windows Terminal Preview v1.14.143.:tada:

Handy links:

• Release Notes
• Store Download