FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Add ConciseView for $ErrorView by SteveL-MSFT · Pull Request #10641 · PowerShell/PowerShell · GitHub

Add ConciseView for $ErrorView - #10641

Merged
Andrew (anmenaga) merged 26 commits into
PowerShell:masterfrom
SteveL-MSFT:errorview
Oct 4, 2019
Merged

Add ConciseView for $ErrorView#10641
Andrew (anmenaga) merged 26 commits into
PowerShell:masterfrom
SteveL-MSFT:errorview

Conversation

Steve Lee (SteveL-MSFT) commented Sep 27, 2019
edited
Loading

Copy link
Copy Markdown
Member

PR Summary

Add new ConciseView as Experimental Feature. When this ExperimentalFeature is enabled, it defaults to ConciseView, otherwise, it defaults to NormalView. CategoryView is still supported.
With new ConciseView, if the error is not from a script or parser error, then it's a single line error message. Otherwise, you get a multiline error message that isn't all red showing the script file (if available), line
that contains the error and a pointer and error message showing where the error is in that line. If the terminal doesn't support Virtual Terminal, then vt100 color codes are not used. The error message within the line display will wrap at whitespace making it easier to read.

A new $Host.PrivateData.ErrorAccentColor member is added so users can customize the color. $ErrorView is now of type [System.Management.Automation.ErrorView] instead of a string.

Some cleanup to the formatting script with regards to double double quotes vs single quotes where appropriate. Also changed the PositionMessage when truncating to use unicode ellipsis instead of 3 dots.

PR Context

Implement $ErrorView part of PowerShell/PowerShell-RFC#228

Fix #3647

PR Checklist

Copy link
Copy Markdown
Collaborator

Steve Lee (@SteveL-MSFT) would it make sense to color the token / ast element in the quoted line(s) that caused the error in red? For parse exceptions, maybe highlighting everything after the point it occurs is best, but having the troublesome cmdlet or argument highlighted in red may make this significantly more readable, and obviates the need for an arrow pointing at it, which (in conjunction with leading whitespace) takes up space that may be needed to display the error message itself.

Copy link
Copy Markdown
Member Author

Rain Sallow (/u/ta11ow) (@vexx32) there are certainly other visualization improvements we could consider. One concern about using some highlight on the section in question without the arrow pointing is that it wouldn't work well on systems that don't support vt100. The current solution will detect the terminal doesn't support VT and simply omit the color codes but the content is still consumable.

Rain Sallow (/u/ta11ow) (vexx32) commented Sep 28, 2019
edited
Loading

Copy link
Copy Markdown
Collaborator

Steve Lee (@SteveL-MSFT) understood, but I imagine combining the arrow with a highlight probably is still a good idea for VT-enabled terminals? 🙂

Copy link
Copy Markdown
Member Author

Rain Sallow (/u/ta11ow) (@vexx32) let me try something to see how it looks

Copy link
Copy Markdown

James Truher (@JamesWTruher) Can you please review this when you get a chance? Thank you.

Copy link
Copy Markdown
Collaborator

Steve Lee (@SteveL-MSFT) very nice! Could we potentially have the first line mention Get-Item: error at ... instead of just Get-Item: at ... ?

It would also be nice to put on the board for the future that you could have Get-Item: fatal error at ... for terminating errors. 🙂

Copy link
Copy Markdown
Member Author

Rain Sallow (/u/ta11ow) (@vexx32) don't have a way yet to determine if terminating or non-terminating, when that eventually shows up, we can update this. I change the text to error in instead of the current in (which is already better than at since the line number isn't on that line anymore)

Copy link
Copy Markdown
Member Author

Rain Sallow (/u/ta11ow) (@vexx32) checkout the updated image above. I wonder if error in should be in error color?

Copy link
Copy Markdown
Collaborator

Steve Lee (@SteveL-MSFT) yeah I'd say that's a good idea.

Keith Hill (rkeithhill) commented Oct 2, 2019
edited
Loading

Copy link
Copy Markdown
Collaborator

I wonder if error in should be in error color?

I don't think it adds much to display error in using the error color. It isn't part of any actual error message.

…ages where the

width didn't take into account vt100 code characters

Copy link
Copy Markdown
Member Author

Keith Hill (@rkeithhill) it makes the file path pop out more, but I'm ok either way

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I don't think there's anything blocking other than the actual bugs in the string truncator

Co-Authored-By: James Truher [MSFT] <jimtru@microsoft.com>
Andrew (anmenaga) merged commit 8cf9c01 into PowerShell:master Oct 4, 2019
Steve Lee (SteveL-MSFT) deleted the errorview branch October 5, 2019 01:18

Copy link
Copy Markdown
Collaborator

The era of color television PowerShell :-)

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log

Projects

None yet

7 participants


Back | FazBrowse Home | New Git URL