Spaces added to prompt on shell launch (PowerShell/pwsh)

[yooakim]

Environment

Win32NT 10.0.19042.0 Microsoft Windows NT 10.0.19042.0
Windows Terminal Version: 1.4.3141.0

https://github.com/justjanne/powerline-go

Steps to reproduce

Add the following to your PowerShell $PROFILE (adjust the path to the powerline-go exectuable to your local environment)

Function global:prompt {
    $pwd = $ExecutionContext.SessionState.Path.CurrentLocation
    $startInfo = New-Object System.Diagnostics.ProcessStartInfo
    $startInfo.FileName = "$ENV:OneDriveConsumer\Util\powerline-go.exe"
    $startInfo.Arguments = "-shell bare"
    $startInfo.Environment["TERM"] = "xterm-256color"
    $startInfo.CreateNoWindow = $true
    $startInfo.StandardOutputEncoding = [System.Text.Encoding]::UTF8
    $startInfo.RedirectStandardOutput = $true
    $startInfo.UseShellExecute = $false
    $startInfo.WorkingDirectory = $pwd
    $process = New-Object System.Diagnostics.Process
    $process.StartInfo = $startInfo
    $process.Start() | Out-Null
    $standardOut = $process.StandardOutput.ReadToEnd()
    $process.WaitForExit()
    $standardOut
}

Start a PowerShell (classic) or PowerShell terminal window via Windows Terminal. The first time the prompt function is called there are spaces inserted between the different prompt parts. Pressing Enter makes these disappear and the prompt works fine.

If I use the same profile without Windows Terminal launching PowerShell.exe directly it works fine. So I suspect this is related to Windows Terminal.

Here's an animated GIF that shows what is going on:

Expected behavior

I expect to see the prompt formatted correctly as follows:

Actual behavior

This is what the prompt looks like when the PowerShell is first started:

[zadjii-msft]

This might sound crazy, but if you highlight that first prompt line, the one with the spaces, then dismiss the selection, does it re-render correctly?

[DHowett]

It looks like you've customized your powershell profile somewhat? I can't reproduce this, but I am not using -NoLogo or have otherwise suppressed the startup banner. 🤔

[DHowett]

Yeah, this only happens with -NoLogo. Interesting!

@zadjii-msft this is coming out of conpty with additional \e[1C in it, but only on the first-ever print to the screen. Everything else comes out fine.

First run

␛[38;5;250m␛[48;5;240m␛[H␣REDMOND\duhowett␛[38;5;240m␛[48;5;238m␛[1C␛[38;5;250m␛[1Cdhowett-sl␛[38;5;238m␛[48;5;31m␛[1C␛[38;5;15m␛[1C~␛[38;5;31m␛[48;5;236m␛[1C␛[38;5;15m␛[1C$␛[38;5;236m␛[49m␛[1C␛[1C␛

After Clear

␛[38;5;250m␛[48;5;240m␣REDMOND\duhowett␣␛[38;5;240m␛[48;5;238m␣␛[38;5;250mdhowett-sl␣␛[38;5;238m␛[48;5;31m␣␛[38;5;15m~␣␛[38;5;31m␛[48;5;236m␣␛[38;5;15m$␣␛[38;5;236m␛[49m␣␛[m

[zadjii-msft]

well that's batty. Thanks for investigating! @DHowett any chance you've got a oneliner repro for me that I can turn into a test? (if not that's cool too, this is probably enough to work off of)

EDIT: J/K read the OP again, that's simple enough. I was worried I had to install a module or something.

[DHowett]

Nah, it's even easier!

test_8341.ps1

"`e[38;5;250m`e[48;5;240m REDMOND\duhowett `e[38;5;240m`e[48;5;238m `e[38;5;250mdhowett-sl `e[38;5;238m`e[48;5;31m `e[38;5;15m~ `e[38;5;31m`e[48;5;236m `e[38;5;15m$ `e[38;5;236m`e[49m `e[m"
sleep 100

wt nt pwsh -c test_8341.ps1

[DHowett]

Just so long as it's the first thing printed to the screen. I used the powershell core escape escape, so it won't work in Windows PowerShell (sorry)

[yooakim]

I've been off-line for a while but thanks for the looking into this :-)

[ntaken]

hmm.. Have the same thing happening to me with Windows terminal Version: 1.4.3243.0 but with Ubuntu wsl after following this guide [https://docs.microsoft.com/sv-se/windows/terminal/tutorials/powerline-setup] .
Works fine with wsl.exe.

Resizing the window or open any file and close it will fix the stripes.

[brunovieira97]

My Windows Terminal was updated yesterday and this started happening for me. Even though I always use up to date versions of everything (or did so until 2 months ago), this never happened before.

Any update on this?

[ghost]

I can confirm that this happens with the -NoLogo option, and only on the first prompt:

As a workaround, I've added a cls to my PS profile, which had no impact on launch time:

Import-Module posh-git
Import-Module oh-my-posh
Set-PoshPrompt Paradox
Clear-Host

[DHowett]

How strange! Would you be willing to try and capture this with the debug tap?

[DHowett]

Wait, I forgot that we already had a repro for this. You can ignore that request!

[brunovieira97]

@DHowett if you need any assistance in reproducing, or more information on it, count on me! I'm interested in helping in any way I can ;)

[wu-yue-yu]

ah, I have the same problem. But it perfoms normally before, just becomes like this when I accidentally change the cmd profile. Then my wsl looks like this.

[wu-yue-yu]

My Windows Terminal was updated yesterday and this started happening for me. Even though I always use up to date versions of everything (or did so until 2 months ago), this never happened before.

Any update on this?

Maybe because of the update? Me too. It jumps out recently.

[DHowett]

HA! We finally have a root cause for this. I ran into a different issue, where the "version update" notification was losing the background color around the edges, and it all started to fall into place.

If we are painting the first frame or any frame after you clear the entire screen, as an optimization[^1] we don't send a bunch of space characters. We neglected to check whether those space characters were meaningful (had background colors, underlines, other attributes...). This happens for each run of text (so, region of text bordered by a color/attribute change), not per line.

Proximal area of failure:

terminal/src/renderer/vt/paint.cpp

Lines 448 to 462 in 27de97b

	// If we're not using erase char, but we did erase all at the start of the
	// frame, don't add spaces at the end.
	//
	// GH#5161: Only removeSpaces when we're in the _newBottomLine state and the
	// line we're trying to print right now _actually is the bottom line_
	//
	// GH#5291: DON'T remove spaces when the row wrapped. We might need those
	// spaces to preserve the wrap state of this line, or the cursor position.
	// For example, vim.exe uses "~ "... to clear the line, and then leaves
	// the lines _wrapped_. It doesn't care to manually break the lines, but if
	// we trimmed the spaces off here, we'd print all the "~"s one after another
	// on the same line.
	const bool removeSpaces = !lineWrapped && (useEraseChar ||
	_clearedAllThisFrame ||
	(_newBottomLine && printingBottomLine && bgMatched));

I wonder if we can use this function to help:

terminal/src/buffer/out/TextAttribute.hpp

Lines 135 to 137 in 27de97b

	// This returns whether this attribute, if printed directly next to another attribute, for the space
	// character, would look identical to the other one.
	bool HasIdenticalVisualRepresentationForBlankSpace(const TextAttribute& other, const bool inverted = false) const noexcept

[^1] The ConPTY API tries very hard to pretend that it is not translating a buffer of 120x30 cells into VT . . . so it lies, cheats and steals sometimes. The buffer contains 3900 empty spaces on startup, so we try not to send them to apps.

[DHowett]

It's testable!
I am not certain the right way to fix it, but it's fixable too. The test passes as of c9e2069, but the attribute math is not correct (to which I suspect @j4james will attest)

[ghost]

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

Handy links:

• Release Notes
• Store Download

[ghost]

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

Handy links:

• Release Notes
• Store Download

[Un1q32]

i seem to have a similar issue

It's different on different font sizes. The above screenshot is with a font size of 12, but with a font size of 13 the gaps disappear.

[zadjii-msft]

@OldWorldOrdr Nah, that's more like, well, one of these: https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+line+drawing

There's a few of those, so it's hard to point the finger at just one.