Whilst one wouldn't want things special cased and hard-coded to terminals, one can actually detect if PowerShell is hosted within ConEmu via environment variables.
Therefore what do you think about a best effort approach of trying to detect well known terminals like ConEmu or the Windows terminal and have a different default if and only if it can be detected with confidence.

Christoph Bergmeister (@bergmeister) does ConEmu have a big enough customer base to warrant such code? Also, does every version of ConEmu support it? In the case of Windows Terminal, we'd have to check that it's newer than a specific version to turn it on by default.

Steve Lee (@SteveL-MSFT) Christoph Bergmeister (@bergmeister) I worry about doing automatic terminal detection being a slippery slope of the team having to support all kinds of terminal quirks long-term, when it's easy enough to do the detection in a user profile. Especially when being done with something as arbitrary as environment variables vs. some sort of standard cross-platform terminal feature detection process (which doesn't exist to my knowledge)

This kind of detection could also easily be done in a separate module that manages PSStyle, I don't think it should be part of the core PS codebase however.

Steve Lee (@SteveL-MSFT) It would be nice if you can add screenshot or GIF to show how this looks in Windows Terminal.

Dongbo Wang (@daxian-dbw) added a gif, you can see it in the upper left of the tab. It's just a little circle that fills in based on % complete

Changed PR title so that changelog generation script won't have problems with it.

🎉v7.2.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

Given that the OSC progress indicator is a "write-only" thing, there are a number of scenarios where the result is not what one would expect IMVHO:

1. a;b;c;d one-liner where a sets the indicator to "indeterminate" using OSC9;4;3;100BEL, b launches a script that uses Write-Progress, c performs some time-consuming actions, and d resets the indicator using OSC9;4;0;100BEL: the "indeterminate" indicator is overwritten by the Write-Progress so during the execution of c the indicator is not the "indeterminate" one but the "0%" one
2. If a script shows its progress using Write-Progress and uses Compress-Archive, the indicator set by the former is overwritten by the one set by the latter, so the indicator that's visible most of the time is 0% since that's what it's reset to at the end of the Compress-Archive

This can be experimented with something like this:

param([int] $Count = 10, [int] $Delay = 10, [switch] $Archive)

for ($i=0; $i -lt $Count; $i++)
{
    Write-Host ("{0}/{1}" -f $i, $Count)
    Write-Progress -Activity 'Activity' -Status 'Status' -PercentComplete (100 * ($i+1) / $Count)
    if ($Archive)
    {
        Remove-Item c:/tmp/foo.zip -ea 0
        Compress-Archive -destination c:/tmp/foo.zip C:\Users\steph\OneDrive\Images\*.cr2
    }
    Start-Sleep -Seconds $Delay
}
Write-Progress -Activity 'Activity' -Status 'Status' -Completed

I think what we need is some global stack-based encapsulation of the indicator, where the latest desired indicator is "pushed" to the top of the stack, and the indicator is restored to the previous state on a "pop" operation.

This needs to be solved for all nested and coterminous progress operations regardless of OSC indication. OSC indication being mixed up is only one symptom of the underlying issue. 😄

This needs to be solved for all nested and coterminous progress operations regardless of OSC indication. OSC indication being mixed up is only one symptom of the underlying issue. 😄

Where is discussed / tracked?

Are the a / d parts of my scenario #1 covered?