By not doing excessive amounts of extra work, formatting can be sped up quite significantly (about 8x faster).
The main change comes from adding new, more efficient, primitive to query an object for the existence of an instance member.
The formatting system has been checking for if an object has properties other than some decorated properties added by PS remoting, and it doesn't this by retrieving all properties which results in heavy allocations and wasted cycles.
By adding `GetFirstOrDefault` to `PSObject` and similar primitives to the underlying Adapters, we are able to return early, without having to get all properties back.
When using a screen reader or just getting the output of a table with lots of rows, the header is no longer on the screen and the columns may no longer make sense without the context. This change adds a `-RepeatHeader` switch to `Format-Table` to enable re-outputting the header after every screen full (minus 1 row). Expectation is that the user is piping the output to a pager (e.g. less) which uses the bottom row for pager information. I followed the `AutoSize` parameter as the way to get the parameter from the cmdlet into the deep formatting object where it's needed.
change ellipsis when truncating to single unicode character
reset console output if previous column contains ESC
update existing format-table tests
If content included a VT100 ESC sequence (like changing color), this affected all output after that cell in the table. Fix is to detect that a cell contained ESC and reset the console after it. Also, change the 3 character ellipsis `...` to use the single unicode character `…` so that more text is available.
Fix https://github.com/PowerShell/PowerShell/issues/7767
* Adding support for built-in List formats to include ItemSelectionCondition
* Adding ItemSelectionCondition to GenericMeasureInfo
* Adding tests for MeasureInfo format-list
* Adding positive tests
Default to DefaultConsoleWidth when DotNet says WindowWidth is 0
This resolves an issue in an environment like VSTS when pwsh is spawned and DotNet is not able to determine the Console Width.
* Port changes from #6883 by @kalgiz
Table formatter was overly aggressive in removing padding so even right justified output (default of numbers) gets incorrectly stripped of padding. Fix is when right justified, always add padding (because it's right justified, there's never trailing whitespace).
Measure-Object should handle `ScriptBlock` properties. Fixed by renaming `MshExpression` to `PSPropertyExpression` and making it public. Then in `MeasureObjectCommand`, lifting it up to the parameter level. Previously the implementation exposed the Property as a string and
wrapped it internally as a `PSPropertyExpression`. Now the parameter type is `PSPropertyExpression` directly allowing for both wildcard strings and `ScriptBlock`.
`PSPropertyExpression` now lives in a public namespace where it can be used by cmdlet and script authors to easily add the same type of functionality to their commands. I also modified `PSPropertyExpression` to handle hashtables properly as objects so
@{prop = 3} | measure-object prop
and
@{prop = 3} | measure-object {$_.prop}
will work the same. (Previously the example using just the property name would fail.)
Dynamic (DLR) objects work in some places today, but not others. This change expands that support to ForEach-Object, Where-Object and the family of cmdlets that use 'MshExpression' (Select-Object, etc.).
This change addresses both wildcard and non-wildcard cases. In wildcard cases, it uses the existing support of generating PSDynamicMember objects for names returned by GetDynamicMemberNames.
In non-wildcard cases, a dynamic property access is attempted whether or not the name shows up in GetDynamicMemberNames, but a truly "blind" access is only attempted if we see that the base object is an IDMOP. If the dynamic access fails, you'll get the same or a similar error experience as before ("The property 'Blarg' cannot be found", or no error at all, depending on the cmdlet and the strict mode setting).
The included test coverage includes a stub for the.ForEach operator--once people are happy with this change, I can continue by adding support there.
This change should allegedly also have positive perf impact, though in actual perf testing, although it does seem ever-so-slightly faster, I found it difficult to measure much difference at all.
Steve Lee