Reimplement the VT tab stop functionality

[j4james]

Summary of the Pull Request

This is essentially a rewrite of the VT tab stop functionality, implemented entirely within the AdaptDispatch class. This significantly simplifies the ConGetSet interface, and should hopefully make it easier to share the functionality with the Windows Terminal VT implementation in the future.

By removing the dependence on the SCREEN_INFORMATION class, it fixes the problem of the the tab state not being preserved when switching between the main and alternate buffers. And the new architecture also fixes problems with the tabs not being correctly initialized when the screen is resized.

References

This fixes one aspect of issue #3545.
It also supersedes the fix for #411 (PR #2816).
I'm hoping the simplification of ConGetSet will help with #3849.

PR Checklist

• Closes Issue with line-wrapped tabstops after resizing the window #4669
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Requires documentation to be updated
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

In the new tab architecture, there is now a vector<bool> (_tabStopColumns), which tracks whether any particular column is a tab stop or not. There is also a _initDefaultTabStops flag indicating whether the default tab stop positions need to be initialised when the screen is resized.

The way this works, the vector is initially empty, and only initialized (to the current width of the screen) when it needs to be used. When the vector grows in size, the _initDefaultTabStops flag determines whether the new columns are set to false, or if every 8th column is set to true.

By default we want the latter behaviour - newly revealed columns should have default tab stops assigned to them - so _initDefaultTabStops is set to true. However, after a TBC 3 operation (i.e. we've cleared all tab stops), there should be no tab stops in any newly revealed columns, so _initDefaultTabStops is set to false.

Note that the _tabStopColumns vector is never made smaller when the window is shrunk, and that way it can preserve the state of tab stops that are off screen, but which may come into range if the window is made bigger again.

However, we can can still reset the vector completely after an RIS or TBC 3 operation, since the state can then be reconstructed automatically based on just the _initDefaultTabStops flag.

Validation Steps Performed

The original screen buffer tests had to be rewritten to set and query the tab stop state using escape sequences rather than interacting with the SCREEN_INFORMATION class directly, but otherwise the structure of most tests remained largely the same.

However, the alt buffer test was significantly rewritten, since the original behaviour was incorrect, and the initialization test was dropped completely, since it was no longer applicable. The adapter tests were also dropped, since they were testing the ConGetSet interface which has now been removed.

I also had to make an addition to the method setup of the screen buffer tests (making sure the viewport was appropriately initialized), since there were some tests (unrelated to tab stops) that were previously dependent on the state being set in the tab initialization test which has now been removed.

I've manually tested the issue described in #4669 and confirmed that the tabs now produce the correct spacing after a resize.

[DHowett-MSFT]

Class act as always. Thank you, @j4james

[zadjii-msft]

So wait, just to be clear, the main and alt buffer are supposed to share one set of tab stops?

[j4james]

So wait, just to be clear, the main and alt buffer are supposed to share one set of tab stops?

Yep. There's a test case in #3545 which demonstrates this issue and a screenshot of the XTerm behaviour. VTE and Mintty work the same way.

[j4james]

Note that build failure is just a timeout in the unit tests. The second last commit was fine, and the one that followed was just a comment fix, so no reason it should make any difference.

[DHowett-MSFT]

Kicked the failed test.

[DHowett-MSFT]

The two Mikes, who would otherwise be reviewing and/or signing off, aren't available today -- this might take a little bit to get merged, but I'll tag it for Auto and Second.

[ghost]

Hello @DHowett-MSFT!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[DHowett-MSFT]

@msftbot make sure @zadjii-msft signs off

[ghost]

Hello @DHowett-MSFT!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I'll only merge this pull request if it's approved by @zadjii-msft

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[j4james]

The two Mikes, who would otherwise be reviewing and/or signing off, aren't available today -- this might take a little bit to get merged, but I'll tag it for Auto and Second.

That's cool. I wasn't expecting you'd even look at it before the v1 release. I'm not in any rush to get anything merged.

[zadjii-msft]

Thanks for clarifying!

[ghost]

🎉Windows Terminal Preview v0.11.1121.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download