starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-30 21:57:23 +00:00 by claunia · 22 comments
claunia commented 2026-01-30 21:57:23 +00:00
Owner
Copy Link

Originally created by @AloyseTech on GitHub (Apr 15, 2019).

Originally assigned to: @zadjii-msft on GitHub.

  • 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)
    git_messed

  • 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.

Originally created by @AloyseTech on GitHub (Apr 15, 2019). Originally assigned to: @zadjii-msft on GitHub. * 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) ![git_messed](https://user-images.githubusercontent.com/13847288/56122214-2600ae00-5f72-11e9-83c7-dd795fd0db70.PNG) * 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.
claunia commented 2026-01-30 21:57:25 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jul 3, 2019):

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.

@j4james commented on GitHub (Jul 3, 2019): 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.
claunia commented 2026-01-30 21:57:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 3, 2019):

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

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 commented on GitHub (Jul 3, 2019): I'm pretty sure we mucked with this _very_ recently. ![image](https://user-images.githubusercontent.com/18356694/60608492-35c7ab80-9d85-11e9-9a2a-d6c2c7e92ae2.png) 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.
claunia commented 2026-01-30 21:57:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 3, 2019):

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?

@zadjii-msft commented on GitHub (Jul 3, 2019): 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?
claunia commented 2026-01-30 21:57:25 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Jul 3, 2019):

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

@AloyseTech commented on GitHub (Jul 3, 2019): I still have the issue on Windows 10 17763.557. Do I need to update WSL alone somehow?
claunia commented 2026-01-30 21:57:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 3, 2019):

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

@zadjii-msft commented on GitHub (Jul 3, 2019): @AloyseTech Oh, I mean you need to update Windows 10 to 18362
claunia commented 2026-01-30 21:57:26 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Jul 3, 2019):

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...

@AloyseTech commented on GitHub (Jul 3, 2019): 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...
claunia commented 2026-01-30 21:57:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 3, 2019):

Good to know! I'll move it to the right milestone and investigate soontm

@zadjii-msft commented on GitHub (Jul 3, 2019): Good to know! I'll move it to the right milestone and investigate soon<sup>tm</sup>
claunia commented 2026-01-30 21:57:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 5, 2019):

Hmm. I can't seem to repro this:
image

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 commented on GitHub (Sep 5, 2019): Hmm. I can't seem to repro this: ![image](https://user-images.githubusercontent.com/18356694/64362583-6372e000-cfd4-11e9-9f62-2c6e47fa1a63.png) 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?
claunia commented 2026-01-30 21:57:26 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 10, 2019):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Sep 10, 2019): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
claunia commented 2026-01-30 21:57:27 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Sep 10, 2019):

My zshrc has nothing special in it, only a few aliases... is there any particular configuration file I should look into?

@AloyseTech commented on GitHub (Sep 10, 2019): My zshrc has nothing special in it, only a few aliases... is there any particular configuration file I should look into?
claunia commented 2026-01-30 21:57:27 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 11, 2019):

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.

@zadjii-msft commented on GitHub (Sep 11, 2019): 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.
claunia commented 2026-01-30 21:57:27 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 11, 2019):

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

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 commented on GitHub (Sep 11, 2019): I can still reproduce this with a recent local build (commit 537258a60fd9b3e62474b0d432330cc6b78742ed). 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.
claunia commented 2026-01-30 21:57:27 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 11, 2019):

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:

537258a60f/src/host/screenInfo.cpp (L72-L75)

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.

12d2e170dd/src/host/getset.cpp (L409-L414)

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.

@j4james commented on GitHub (Sep 11, 2019): 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: https://github.com/microsoft/terminal/blob/537258a60fd9b3e62474b0d432330cc6b78742ed/src/host/screenInfo.cpp#L72-L75 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. https://github.com/microsoft/terminal/blob/12d2e170dd0ff0e23c956a754a308c4ce3f0c1f8/src/host/getset.cpp#L409-L414 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.
claunia commented 2026-01-30 21:57:27 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 11, 2019):

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!

@zadjii-msft commented on GitHub (Sep 11, 2019): 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!
claunia commented 2026-01-30 21:57:28 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 24, 2019):

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

Handy links:

@ghost commented on GitHub (Sep 24, 2019): :tada: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](https://github.com/microsoft/terminal/releases/tag/v0.5.2661.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 21:57:28 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Jan 16, 2020):

@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 :
image

@AloyseTech commented on GitHub (Jan 16, 2020): @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 : ![image](https://user-images.githubusercontent.com/13847288/72525553-b4d58a80-3864-11ea-85f4-d7c77c26d5f2.png)
claunia commented 2026-01-30 21:57:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 16, 2020):

@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.

@zadjii-msft commented on GitHub (Jan 16, 2020): @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.
claunia commented 2026-01-30 21:57:28 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Jan 16, 2020):

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

@AloyseTech commented on GitHub (Jan 16, 2020): @zadjii-msft I'm running Windows 10 1909 18363.592
claunia commented 2026-01-30 21:57:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 17, 2020):

... 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?

@zadjii-msft commented on GitHub (Jan 17, 2020): ... 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?
claunia commented 2026-01-30 21:57:29 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 17, 2020):

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

@DHowett-MSFT commented on GitHub (Jan 17, 2020): Alas! 18363 is "19H2", a targeted set of backports to 19H1. :smile:
claunia commented 2026-01-30 21:57:29 +00:00
Author
Owner
Copy Link

@AloyseTech commented on GitHub (Jan 24, 2020):

So the fix is not yet ready, right?

@AloyseTech commented on GitHub (Jan 24, 2020): So the fix is not yet ready, right?
claunia commented 2026-01-30 21:57:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 24, 2020):

@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.

@zadjii-msft commented on GitHub (Jan 24, 2020): @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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Output Area-VT Issue-Bug Needs-Tag-Fix Priority-2 Product-Conhost Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#627
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?