This commit completely removes the iostreams.NewColorScheme() initializer function in favor of exporting the type fields for greater clarity in its use.
The result being code specifying only the fields that matter to test cases.
This commit implements the actual changes around configuration setting / environment variable logic for displaying labels using their RGB hex color code in terminals with truecolor support.
One of the subtler changes in this commit is renaming generic ColorScheme.HexToRGB logic to render truecolor to ColorScheme.Label as this feature was being used exclusively for labels. This is due to confusion about introducing the new `color_labels` config on top of generic coloring logic.
This commit is focused on incorporating cli/go-gh accessible colors configuration setting into GitHub CLI experience along with new color function to supersede ColorScheme.Gray and ColorScheme.Grayf.
Originally, I was considering having all use of ColorScheme.Gray and ColorScheme.Grayf fallback to the new muted logic if accessible colors were enabled, however I decided not being that it exceeds the acceptance criteria. This means that every command using ColorScheme.Gray needs to be updated to use ColorScheme.Muted
This commit refactors the color format around table headers to ensure the GitHub CLI uses thematically appropriate colors based on dark background, light background, or no color at all.
In order to do so, `ColorScheme` needs information from the terminal about the background appearance (dark, light, none) to determine appropriate muted color.
On non-Windows platforms, this avoids wrapping `IOStreams.Out` in a
`fdWriter` and thus causing subprocesses to lose connection to the
terminal that gh is connected to.
This ensures that `IOStreams.Out` always keeps the original `Fd()` value even if it's wrapped as a Colorable stream for Windows in cases when enabling virtual terminal processing has failed.
While a gh command is writing stdout to a pager, the user may choose to
close the pager program before the pager has read all the data on its
standard input. In that case, the parent gh process will receive an
EPIPE error, which would bubble up its error handling and cause it to
print something like:
write |1: broken pipe
Since this was caused by an explicit user action of closing the pager,
and since the user probably doesn't want to see this uninformative
error, this informs our global error handling of this error and causes
it to be ignored.
* Rework logging, showing progress, and printing from `codespace` commands
* Change rendering of the general progress indicator so that it's visible on both dark and light backgrounds
* The progress indicator now "spins" faster
Co-authored-by: Mislav Marohnić <mislav@github.com>
* Re-enable label colors for issue list
* Drop parentheses wrapping issue labels
* Support ANSI escape codes in TablePrinter cells
* Switch to a Truncate implementation that correctly measures ANSI escape codes
* Only output RGB color if terminal has truecolor capabilities
* Enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` on Windows - fixes wrapping issues with full lines and allows truecolor rendering
Co-authored-by: Mislav Marohnić <mislav@github.com>
If `GH_PAGER` is exists, set it as the pager even if one is
already set in config.
This allows a user to change/disable the pager per single invocation.
We used to send the ANSI sequence for "bright black" when we wanted gray, but this color turns out to not be visible in some popular color schemes.
Instead, when we detect a 256-color terminal, switch to displaying a color sequence for gray that is consistent and does not depend on terminal color scheme.
Unset PAGER environment variable when executing the command referenced
in PAGER in case that command also has support for PAGER and would end
up executing itself indefinitely.
