Add minimal progress bar using ANSI rendering

[SteveL-MSFT]

PR Summary

The current progress bar is large and complex and provides a different experience on Windows vs Linux/macOS. Redo the progress bar to be a single line leveraging ANSI escape sequence to render progress. $PSStyle.Progress now controls configuration:

$PSStyle.Progress.Style is an ANSI string setting the rendering style
$PSStyle.Progress.MaxWidth sets the max width of the view, defaults to 120. Set to 0 for console width.
$PSStyle.Progress.View is an enum with values Minimal and Classic where Classic is existing rendering with no changes. Current default is Minimal.

Example:

Since this visualization is built into the console host, the new settings would not apply to other hosts like EditorServices.

Fix#14426

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s): PSAnsiProgress
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: Document new ProgressView MicrosoftDocs/PowerShell-Docs#7195
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[SteveL-MSFT]

Noticed an initial rendering issue with the Expand-Archive example I need to fix

[jhoneill]

One of the attractions of the existing progress reporting is it can list things with a fair amount of detail and when they are done, the output goes away. This seems to end up with clutter left behind and the formatting makes it very "attention grabbing"
I would actually want to turn off progress indications if they did that, and would stop using write-progress in my code.

[doctordns]

One of the attractions of the existing progress reporting is it can list things with a fair amount of detail and when they are done, the output goes away. This seems to end up with clutter left behind and the formatting makes it very "attention grabbing"
I would actually want to turn off progress indications if they did that, and would stop using write-progress in my code.

This progress bar and pop up stuff is also an issue for me in VS Code. Using VS Code and doing server management pops up all manner of stuff that obscures what is going on in the screen and does not go away. I'd like to see this addressed in general.

[Jaykul]

One of the attractions of the existing progress reporting is it can list things with a fair amount of detail and when they are done, the output goes away. This seems to end up with clutter left behind and the formatting makes it very "attention grabbing"

The current implementation is far bigger and more attention grabbing -- I wrote a script just last week using Invoke-RestMethod repeatedly which ended up completely obscuring the more important actual output of the script behind a wall of RestMethod progress reports that weren't cleaned up until the script ended.

Obviously one can always turn off progress output (we already do this on PS5.1 because of performance problems), but I think leaving behind a trace of the progress that was is better than the current situation where the progress is totally gone after the fact --regardless of outcome. Currently scripts cannot rely heavily on progress to report state because if they crash, the information is completely lost.

Having said that, I have two other questions:

1. Have you tested this with long status strings? There's currently nothing preventing people from writing multiple lines worth of information into a Status or an Activity, right?
2. Is there an option to still have multi-line output? I'm concerned that using the same space for the text and the progress is going to make this hard to deal with for some users...

[SteveL-MSFT]

@Jaykul regarding long status messages, I did test that and the current PR explicitly truncates it adding an ellipsis to the end. This is similar to how content is truncated in other parts of PowerShell formatting. Anyone writing progress needs to be thoughtful on the information being presented (like long file paths). I'd rather than support multi-line output.

Do you have a scenario that requires multi-line progress output? Keep in mind that nested and multi-progress bars is supported, but each bar is limited to one line currently.

[jhoneill]

One of the attractions of the existing progress reporting is it can list things with a fair amount of detail and when they are done, the output goes away. This seems to end up with clutter left behind and the formatting makes it very "attention grabbing"

The current implementation is far bigger and more attention grabbing -- I wrote a script just last week using Invoke-RestMethod repeatedly which ended up completely obscuring the more important actual output of the script behind a wall of RestMethod progress reports that weren't cleaned up until the script ended.

The important thing is they are cleaned up when the script ends. The job of Write-Progress is to give the user some indication that the script hasn't hung. That's it. If you want information about what happened that's for Write-Debug, or Write-Verbose, or in the case of people who feel the strong urge to generate lots of display on the console Write-hostwith-foreground`

Obviously one can always turn off progress output (we already do this on PS5.1 because of performance problems), but I think leaving behind a trace of the progress that was is better than the current situation where the progress is totally gone after the fact --regardless of outcome.

There are two different requirements, printing "chatty" output which a programmer expects a user to read, and providing something which says "still working, haven't crashed".

Currently scripts cannot rely heavily on progress to report state because if they crash, the information is completely lost.

Nor should they . Imagine if (say) the copy dialog in explorer remained open to tell you how many bytes / files had been copied at what speed afterwards. You don't care, the tasks was completed without errors, you can get on with the next task without stopping to read about what happened which is past your ability to change.

[SteveL-MSFT]

Note that leaving the progress on screen is modeled after various Linux utilities. I can certainly see arguments for both sides.

[jhoneill]

Note that leaving the progress on screen is modeled after various Linux utilities. I can certainly see arguments for both sides.

Well yes, the unix world doesn't have verbose, debug, information and progress to write to, so all manner of garbage goes to standard output (and of course there isn't the distinction between "For human eyeballs" and "Output" that PowerShell has)

Being cleaner and tidier is one of the attractions of PowerShell. Getting the error output to be shorter was held to be a Good Thing, yes?
Developers have figured out what should be transient (something for eyeballs while work is happening) generally don't force users to read stuff they don't need to, and make most of the "hey this is what the program has done" stuff verbose / debug. It works well , but nothing is stopping developers writing commands in the style of Linux, just replace write-verbose with write-host . So this proposal doesn't allow anything extra but would take away something good and distinctive.

Anything which has a loop of display progress message, output a row, and remove the progress message will - I suspect - get the messages interleaved with the output.

[SteveL-MSFT]

Native commands actually use stderr for the purpose of progress/verbose/warning/error messages and stdout is only for output. In this case, it's no different in that pipelining/redirection (unless stream(s) other than output is specified) only happens for output/stdout. I'm thinking of making whether it stays or clears user settable at least during the experimental phase to get real world usage feedback.

[iSazonov]

I'd prefer to keep current (release version) behavior in the PR. I wonder we discuss this in the PR. I think we should discuss this in an issue for all kinds of progress bar. There are some issues with feedback for progress bar. Current design/implementation has fundamental difficulties and we could improve this.

[SteveL-MSFT]

Created #14426, let's have the design discussion there and keep discussion here for code review

[ghost]

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

[SteveL-MSFT]

Found an issue with how progress is rendered when objects are emitted to pipeline. Looks like I'll have to support clearing in all cases to make this work.

[SteveL-MSFT]

Remaining codefactor are existing style or by-design

[iSazonov]

Why don't we use constants for feature names? "PSAnsiProgress" looks like a puzzle.

[SteveL-MSFT]

Good question, we haven't been doing this.

[SteveL-MSFT]

I'll update it for this feature in this PR, but won't update the other ones. We can follow this pattern going forward.

[iSazonov]

Maybe add in the description that is the default.

[SteveL-MSFT]

You mean describe in text what the ANSI escape sequence represents?

[iSazonov]

Maybe ViewStyle if it is a style.

[SteveL-MSFT]

Trying not to overload the style term and use it to mean ANSI decoration. Will change the description to view.

[daxian-dbw]

LGTM with a few comments.

[daxian-dbw]

The CI tests are being flaky recently. I retried the failed CIs twice but both got test failures related to WinCompat:

Additional tests for Import-Module with WinCompat.Tests that ErrorAction/WarningAction have effect when Import-Module with WinCompat is used. Verify that Warning is generated with default WarningAction

Given that the second to last commit had successful CI runs (only CodeFactor failed which can be ignored) and the last commit only made trivial changes to code that is unrelated to the failed WinCompat tests, I will merge this PR.

[daxian-dbw]

@SteveL-MSFT Just noticed a small issue with the new progress bar:

When the MaxWidth is not big enough and the message cannot be fully displayed, I expect the message will be truncated with ellipsis ..., but it displays only 1 dot.

[daxian-dbw]

Ah, another issue, when MaxWidth is too small to have enough space for the [...] part, progress rendering will fail with exceptions:

PS:12> $PSStyle.Progress.MaxWidth = 10 PS:13> Expand-Archive -Path .\source.zip -DestinationPath C:\arena\tmp\deleteme Write-Progress: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:1179 Line | 1179 | Write-Progress -Activity $cmdletName -Status $status -Percent … | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Length cannot be less than zero. (Parameter 'length') Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\' because it | does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\Dockerfile' | because it does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path | 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\devcontainer.json' because it | does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\fedora30\' | because it does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path | 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\fedora30\Dockerfile' because it | does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path | 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.devcontainer\fedora30\devcontainer.json' | because it does not exist. Remove-Item: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:418 Line | 418 | … $expandedItems | %{Remove-Item "$_" -Force -Recurse } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Cannot find path 'C:\arena\tmp\deleteme\PowerShell-7.2.0-preview.1\.editorconfig' because it does | not exist. Write-Progress: C:\arena\repos\powershell\src\powershell-win-core\bin\debug\net5.0\win7-x64\publish\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:1179 Line | 1179 | Write-Progress -Activity $cmdletName -Status $status -Percent … | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Length cannot be less than zero. (Parameter 'length') 

[SeeminglyScience]

Since this visualization is built into the console host, the new settings would not apply to other hosts like EditorServices.

PSES holds onto a copy of ConsoleHost and uses it's implementation of WriteProgress. I don't think it's likely to cause issues, but it will apply there as well.

[ghost]

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

Handy links:

• Release Notes