Terminal layout issue (column count seems off by one ?)

[AloyseTech]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [version 10.0.17763.437]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  using git command line in the terminal in a zsh shell
  git command output layout is messed up (seems like the number of column of the terminal is off by one)
  

• What's wrong / what should be happening instead:
  Wen I open a Ubuntu terminal with WSL, the git commend output layout is messed up. I have to use reset and it fixes the layout in the following commands.

[j4james]

I believe this is an issue with tab stops. It seems that the wsl shell starts up with no tab stops set by default, so when you output a tab, the cursor jumps right to the end of the line.

You can reproduce this with a simple printf "\tX\n". You'd expect that to output the X in column 9, but instead it ends up at the end of the line.

Interestingly the cmd.exe shell doesn't appear to have this problem - it's initialized with tab stops every 8 columns as you'd expect. And if you start a bash shell from the cmd shell then that will have the tab stops set correctly too.

[zadjii-msft]

I'm pretty sure we mucked with this very recently.

Because conhost is insane, we actually have two different sets of tab stops - the VT ones that are used for apps that are using ENABLE_VIRTUAL_TERMINAL_PROCESSING and not cooked reads (ex wsl.exe). These are the ones that were broken here. When an app is using cooked reads (ex cmd.exe), we actually have a separate set of tab-stop logic that's used. The brave could look at the function WriteCharsLegacy to see how the cmd.exe-like tabstops work.

[zadjii-msft]

I want to say this is fixed in the latest release, but I can't get the original case to repro. @AloyseTech can you see if updating Windows fixes this?

[AloyseTech]

I still have the issue on Windows 10 17763.557. Do I need to update WSL alone somehow?

[zadjii-msft]

@AloyseTech Oh, I mean you need to update Windows 10 to 18362

[AloyseTech]

I've just updated to 10.0.18362 (don't know why I was still on the other version), but the problem is still here...

[zadjii-msft]

Good to know! I'll move it to the right milestone and investigate soon^tm

[zadjii-msft]

Hmm. I can't seem to repro this:

Is there anything else about your configuration that might be causing this? Are you maybe running screen or tmux? maybe there's something else that you had previously running in the terminal that left it in a corrupted state? Maybe it's something in your zsh config?

[zadjii-msft]

Honestly I have no idea. Does this repro in other shells? If it doesn't, we can narrow it down to zsh, otherwise we'll have to investigate something else. Since I can't repro this on my own right now, we're going to need to find out what bit of config somewhere is causing this to happen.

[j4james]

I can still reproduce this with a recent local build (commit 537258a).

The trick is to have the VirtualTerminalLevel registry entry set to 1. Then start a shell from the tools directory with openbash, and execute the test case printf "\tX\n".

With VirtualTerminalLevel set to 0 it works (i.e. the X is in column 9). When set to 1, it's at the end of the line.

[j4james]

OK, I think I know what's going on. By default the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode isn't set in the SCREEN_INFORMATION constructor, unless the VirtualTerminalLevel registry is set to a non-zero value:

terminal/src/host/screenInfo.cpp

Lines 72 to 75 in 537258a

	if (gci.GetVirtTermLevel() != 0)
	{
	OutputMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
	}

Later on SetConsoleOutputModeImpl is called with ENABLE_VIRTUAL_TERMINAL_PROCESSING, and that's when the tab stops would usually be initialized, but that only happens if the flag wasn't already set.

terminal/src/host/getset.cpp

Lines 409 to 414 in 12d2e17

	// if we're moving from VT off->on
	else if (WI_IsFlagSet(dwNewMode, ENABLE_VIRTUAL_TERMINAL_PROCESSING) &&
	WI_IsFlagClear(dwOldMode, ENABLE_VIRTUAL_TERMINAL_PROCESSING))
	{
	screenInfo.SetDefaultVtTabStops();
	}

Bottom line, if the ENABLE_VIRTUAL_TERMINAL_PROCESSING was already set in the constructor (because of the registry entry), then the default tab stops don't get initialized.

[zadjii-msft]

Woah. Well that's messed up.

Seems like the easy fix is if we're constructing the buffer with ENABLE_VIRTUAL_TERMINAL_PROCESSING, we should just initialize those tab stops too. Thanks for debugging this @j4james!

[ghost]

🎉This issue was addressed in #2816, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.:tada:

Handy links:

• Release Notes
• Store Download

[AloyseTech]

@zadjii-msft I still have the issue after updating everything I could update. I installed the Terminal Preview as well. Maybe I misunderstanding something, but when I launch WSL terminal via the Ubuntu icon, the terminal TAB is still messed up...
On the left I use Terminal (Preview) and on the right I launch Ubuntu direcly via the shortcut :

[zadjii-msft]

@AloyseTech What Windows version are you using? This was fixed for the Terminal in 0.5, but I'm not sure the Windows release that will fix the legacy/inbox console has actually been released yet.

[AloyseTech]

@zadjii-msft I'm running Windows 10 1909 18363.592

[zadjii-msft]

... I'm realizing now I have now idea how our version numbers work for the last two releases. @DHowett-MSFT I think #2816 landed in Vb, would that be 18363.592 publicly, or is it not out yet?

[DHowett-MSFT]

Alas! 18363 is "19H2", a targeted set of backports to 19H1. 😄

[AloyseTech]

So the fix is not yet ready, right?

[zadjii-msft]

@AloyseTech Nope, looks like it's not. I'm not sure what the next major Windows release build number will be, but that should have the fix.