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

Console doesn't handle colored regions when reflowed #27

New Issue
Closed
opened 2026-01-30 21:39:58 +00:00 by claunia · 16 comments
claunia commented 2026-01-30 21:39:58 +00:00
Owner
Copy Link

Originally created by @bitcrazed on GitHub (Oct 6, 2017).

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    FCU

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

  1. Open Ubuntu session in Console
  2. Execute the following:
$ cd ~/
$ mkdir temp
$ cd temp
$ mkdir hello
$ mkdir world
$ clear 
$ ls
  1. Grab & drag right-hand Console window edge to resize window width

Expected:

Folders' colored background should only extend to the end of the folder name:

image

Actual:

Lines with folders that are last item on line extend folder background coloring to right hand end of line:

image

See the following for an example of where it goes very wrong:
image

And it gets worse when lines wrap!
image

References

Thanks to @jmorrill for reporting here: https://twitter.com/jmorrill/status/915982968094580736

Originally created by @bitcrazed on GitHub (Oct 6, 2017). * Your Windows build number: (Type `ver` at a Windows Command Prompt) FCU * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) 1. Open Ubuntu session in Console 1. Execute the following: ```bash $ cd ~/ $ mkdir temp $ cd temp $ mkdir hello $ mkdir world $ clear $ ls ``` 3. Grab & drag right-hand Console window edge to resize window width ## Expected: Folders' colored background should only extend to the end of the folder name: ![image](https://user-images.githubusercontent.com/961950/31289078-7313e830-aa7c-11e7-90c9-4f1bbbcef30a.png) ## Actual: Lines with folders that are last item on line extend folder background coloring to right hand end of line: ![image](https://user-images.githubusercontent.com/961950/31288941-d433dcc0-aa7b-11e7-91eb-e27f3877cc32.png) See the following for an example of where it goes very wrong: ![image](https://user-images.githubusercontent.com/961950/31289337-3aeb8d2c-aa7d-11e7-8d38-f0574ee0a3b5.png) And it gets worse when lines wrap! ![image](https://user-images.githubusercontent.com/961950/31289368-5652ad3e-aa7d-11e7-82f4-481cdf79914f.png) # References Thanks to @jmorrill for reporting here: https://twitter.com/jmorrill/status/915982968094580736
claunia commented 2026-01-30 21:39:59 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 6, 2017):

So this is basically because we don't know the difference between a space character that was purposefully emitted and just an empty cell in the buffer.

When we resize, we optimize things a little bit by just filling the rest of the row with the last color we saw (as we resize). This causes the rest of the row to fill up with the colors of the last character.

I can make it a bit better, but it will clear out any colored spaces at the end of the row:
image

See how the last two spaces of the white column were reset.

Might be an acceptable hit considering that resizing is already an AWFUL perf path.

(opened msft:14115086 to track)

@zadjii-msft commented on GitHub (Oct 6, 2017): So this is basically because we don't know the difference between a space character that was purposefully emitted and just an empty cell in the buffer. When we resize, we optimize things a little bit by just filling the rest of the row with the last color we saw (as we resize). This causes the rest of the row to fill up with the colors of the last character. I can make it a bit better, but it will clear out any colored spaces at the end of the row: ![image](https://user-images.githubusercontent.com/18356694/31289588-168dc8b8-aa7e-11e7-9431-15adb44f7cab.png) See how the last two spaces of the white column were reset. Might be an acceptable hit considering that resizing is already an AWFUL perf path. (opened msft:14115086 to track)
claunia commented 2026-01-30 21:39:59 +00:00
Author
Owner
Copy Link

@jmorrill commented on GitHub (Oct 6, 2017):

Thanks for looking into this guys.

IMO your suggestion of "I can make it a bit better, but it will clear out any colored spaces at the end of the row" looks more acceptable to me than the current behavior.

Curious what others think.

Windows Version: Microsoft Windows [Version 10.0.16299.15]

@jmorrill commented on GitHub (Oct 6, 2017): Thanks for looking into this guys. IMO your suggestion of "I can make it a bit better, but it will clear out any colored spaces at the end of the row" looks _more_ acceptable to me than the current behavior. Curious what others think. Windows Version: Microsoft Windows [Version 10.0.16299.15]
claunia commented 2026-01-30 21:39:59 +00:00
Author
Owner
Copy Link

@bitcrazed commented on GitHub (Oct 6, 2017):

FWIW, this isn't a problem that's unique to Console - Hyper also struggles to handle this scenario:

image

@bitcrazed commented on GitHub (Oct 6, 2017): FWIW, this isn't a problem that's unique to Console - [Hyper](https://hyper.is/) also struggles to handle this scenario: ![image](https://user-images.githubusercontent.com/961950/31291514-ed7f7730-aa84-11e7-97a1-8b2df7b1a8fa.png)
claunia commented 2026-01-30 21:40:00 +00:00
Author
Owner
Copy Link

@jmorrill commented on GitHub (Oct 6, 2017):

I've also seen this issue in hyper (and VS Code terminal window), but assumed it was something common to all of them and "lower level" in Windows.

@jmorrill commented on GitHub (Oct 6, 2017): I've also seen this issue in hyper (and VS Code terminal window), but assumed it was something common to all of them and "lower level" in Windows.
claunia commented 2026-01-30 21:40:00 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 6, 2017):

That's correct, Hyper and others all query an underlying conhost, so if we've got it wrong then it will be wrong for everyone.

@zadjii-msft commented on GitHub (Oct 6, 2017): That's correct, Hyper and others all query an underlying conhost, so if we've got it wrong then it will be wrong for everyone.
claunia commented 2026-01-30 21:40:00 +00:00
Author
Owner
Copy Link

@parkovski commented on GitHub (Oct 20, 2017):

I have a similar (same?) issue with Vim/WSL with the termguicolors option set.
Before resize:
vim-wsl
After resize:
vim-wsl-resize
Expected (iTerm):
vim-iterm

@parkovski commented on GitHub (Oct 20, 2017): I have a similar (same?) issue with Vim/WSL with the `termguicolors` option set. Before resize: ![vim-wsl](https://user-images.githubusercontent.com/1094150/31839419-d43d2a1c-b595-11e7-86ce-1a2c0c6883ed.png) After resize: ![vim-wsl-resize](https://user-images.githubusercontent.com/1094150/31839420-d45b93da-b595-11e7-8d60-2e19810b8ee2.png) Expected (iTerm): ![vim-iterm](https://user-images.githubusercontent.com/1094150/31839431-e19c98be-b595-11e7-80ec-22e49dcf3429.png)
claunia commented 2026-01-30 21:40:01 +00:00
Author
Owner
Copy Link

@dra27 commented on GitHub (Jan 8, 2018):

I'm sure it's all part of the same thing - this also affects underlined text.

@dra27 commented on GitHub (Jan 8, 2018): I'm sure it's all part of the same thing - this also affects underlined text.
claunia commented 2026-01-30 21:40:01 +00:00
Author
Owner
Copy Link

@ramsay-vibes commented on GitHub (Sep 5, 2019):

Bump: As of Terminal 0.4.2382.0 this is still an issue. Using WSL Ubuntu shell I can recreate this many ways, but one easy way is to execute the following command:

before

Then resize the window and the line is repainted incorrectly:

after-resize

@ramsay-vibes commented on GitHub (Sep 5, 2019): Bump: As of Terminal 0.4.2382.0 this is still an issue. Using WSL Ubuntu shell I can recreate this many ways, but one easy way is to execute the following command: ![before](https://user-images.githubusercontent.com/8571098/64369528-76a5a000-d014-11e9-951d-d0742a044230.png) Then resize the window and the line is repainted incorrectly: ![after-resize](https://user-images.githubusercontent.com/8571098/64369718-d8fea080-d014-11e9-8ac2-933087400a30.png)
claunia commented 2026-01-30 21:40:02 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 27, 2020):

I'm not actually investigating this bug yet, but I had a thought about it. In TextBuffer::Reflow, we could just reset the attr run for the rest of the row when we hit the last column from the old buffer, right? Let's add newBuffer.GetRowByOffset(newCursor.GetPosition().Y).GetAttrRow().SetAttrToEnd(iRight, newBuffer._currentAttributes); to the following code:

        if (SUCCEEDED(hr))
        {
            // If we didn't have a full row to copy, insert a new
            // line into the new buffer.
            // Only do so if we were not forced to wrap. If we did
            // force a word wrap, then the existing line break was
            // only because we ran out of space.
            if (iRight < cOldColsTotal && !charRow.WasWrapForced())
            {
                if (iRight == cOldCursorPos.X && iOldRow == cOldCursorPos.Y)
                {
                    cNewCursorPos = newCursor.GetPosition();
                    fFoundCursorPos = true;
                }
                // Only do this if it's not the final line in the buffer.
                // On the final line, we want the cursor to sit
                // where it is done printing for the cursor
                // adjustment to follow.
                if (iOldRow < cOldRowsTotal - 1)
                {
                    // Hey this might fix the color getting draged to the EOL on resize
                    // ADD THIS LINE HERE VVV
                    newBuffer.GetRowByOffset(newCursor.GetPosition().Y).GetAttrRow().SetAttrToEnd(iRight, newBuffer._currentAttributes);
                    hr = newBuffer.NewlineCursor() ? hr : E_OUTOFMEMORY;
                }

Again, I'm not actually investigating this. This is basically a showerthought

@zadjii-msft commented on GitHub (Mar 27, 2020): I'm not actually investigating this bug yet, but I had a thought about it. In `TextBuffer::Reflow`, we could just reset the attr run for the rest of the row when we hit the last column from the old buffer, right? Let's add `newBuffer.GetRowByOffset(newCursor.GetPosition().Y).GetAttrRow().SetAttrToEnd(iRight, newBuffer._currentAttributes);` to the following code: ```c++ if (SUCCEEDED(hr)) { // If we didn't have a full row to copy, insert a new // line into the new buffer. // Only do so if we were not forced to wrap. If we did // force a word wrap, then the existing line break was // only because we ran out of space. if (iRight < cOldColsTotal && !charRow.WasWrapForced()) { if (iRight == cOldCursorPos.X && iOldRow == cOldCursorPos.Y) { cNewCursorPos = newCursor.GetPosition(); fFoundCursorPos = true; } // Only do this if it's not the final line in the buffer. // On the final line, we want the cursor to sit // where it is done printing for the cursor // adjustment to follow. if (iOldRow < cOldRowsTotal - 1) { // Hey this might fix the color getting draged to the EOL on resize // ADD THIS LINE HERE VVV newBuffer.GetRowByOffset(newCursor.GetPosition().Y).GetAttrRow().SetAttrToEnd(iRight, newBuffer._currentAttributes); hr = newBuffer.NewlineCursor() ? hr : E_OUTOFMEMORY; } ``` Again, I'm not actually investigating this. This is basically a showerthought
claunia commented 2026-01-30 21:40:02 +00:00
Author
Owner
Copy Link

@vblazhkun commented on GitHub (Jul 23, 2020):

That might become more critical due to introduction of toggleFullscreen and toggleFocusMode (especially) which are triggered back and forth for the same terminal window pretty frequently.

@vblazhkun commented on GitHub (Jul 23, 2020): That might become more critical due to introduction of `toggleFullscreen` and `toggleFocusMode` (especially) which are triggered back and forth for the same terminal window pretty frequently.
claunia commented 2026-01-30 21:40:02 +00:00
Author
Owner
Copy Link

@musm commented on GitHub (Jul 23, 2020):

Yeah I do agree with @vblazhkun, this get's annoying

@musm commented on GitHub (Jul 23, 2020): Yeah I do agree with @vblazhkun, this get's annoying
claunia commented 2026-01-30 21:40:02 +00:00
Author
Owner
Copy Link

@yb3616 commented on GitHub (Sep 23, 2020):

Windows Terminal
Version: 1.3.2651.0

When i resize the window

image

what do i expect

image

@yb3616 commented on GitHub (Sep 23, 2020): Windows Terminal Version: 1.3.2651.0 When i resize the window ![image](https://user-images.githubusercontent.com/8839021/93965497-d7755700-fd94-11ea-8124-e553a4cf2cc5.png) what do i expect ![image](https://user-images.githubusercontent.com/8839021/93965703-62565180-fd95-11ea-8e54-8879a63bfc3f.png)
claunia commented 2026-01-30 21:40:03 +00:00
Author
Owner
Copy Link

@musm commented on GitHub (Sep 23, 2020):

Please post an issue or something more descriptive than just a screenshot.

@musm commented on GitHub (Sep 23, 2020): Please post an issue or something more descriptive than just a screenshot.
claunia commented 2026-01-30 21:40:03 +00:00
Author
Owner
Copy Link

@plastikfan commented on GitHub (Feb 9, 2021):

FWIW, I discovered a workaround as a result of posting this question to stackoverflow. If you write a non-breaking space, like so:

write-host 'hello' -f 'red' -b 'cyan' -n; write-host ([char]0xA0)

patches the issue. Works in Windows Terminal, Windows Console and Fluent Terminal. Not sure if this is an issue on macOS with iterm2/terminal (not sure about linux).

@plastikfan commented on GitHub (Feb 9, 2021): FWIW, I discovered a workaround as a result of posting [this question to stackoverflow](https://stackoverflow.com/questions/66123718/write-host-with-background-colour-fills-the-entire-line-with-background-colour-w). If you write a non-breaking space, like so: > write-host 'hello' -f 'red' -b 'cyan' -n; write-host ([char]0xA0) patches the issue. Works in Windows Terminal, Windows Console and Fluent Terminal. Not sure if this is an issue on macOS with iterm2/terminal (not sure about linux).
claunia commented 2026-01-30 21:40:03 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 19, 2022):

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

Handy links:

@ghost commented on GitHub (Apr 19, 2022): :tada:This issue was addressed in #12637, which has now been successfully released as `Windows Terminal v1.12.1098`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.12.1098) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 21:40:04 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 19, 2022):

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

Handy links:

@ghost commented on GitHub (Apr 19, 2022): :tada:This issue was addressed in #12637, which has now been successfully released as `Windows Terminal Preview v1.13.1098`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.13.1098) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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-Rendering Impact-Visual Issue-Bug Priority-3 Product-Conhost Resolution-Fix-Committed Work-Item
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#27
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?