Introduce a new Prompter implementation (huhPrompter) that uses the
charmbracelet/huh library in its standard interactive mode, as an
alternative to the survey-based default prompter. The new implementation
is gated behind the GH_EXPERIMENTAL_PROMPTER environment variable,
following the same truthy/falsey pattern as GH_ACCESSIBLE_PROMPTER.
Key differences from the accessible prompter:
- No WithAccessible(true) flag (full interactive TUI)
- Uses EchoModePassword (masked with *) instead of EchoModeNone
- No default value annotations appended to prompt text
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This bypasses the `spinner` package for the textual progress indicator for users
with the spinner disabled out of concerns for accessibility, specifically
with screen readers:
- The `spinner` package will continuously re-draw the screen. I wasn't
able to have this cause problems with my Mac screen reader, but it's
nonetheless a concern that other screen readers may not handle this
screen re-drawing well.
- The `spinner` package clears any progress indicator messages from the screen
when stopping the progress indicator or changing its label.
This is a problem because it interrupts screen readers and leaves no way
to recover what the loading message was by scrolling up in the terminal.
NOTE: this new implementation still interrupts the screen reader when
the a new label is printed, but it does not clear the screen. This makes
the loading messages recoverable, at least.
- Move env var evaluation to the factory defaults.
- Use only the label for the spinner instead of adding
"working..." every time. "working..." remains the default
when no label is provided.
This commit converts all of the places using ColorScheme.Gray and ColorScheme.Grayf to Muted and Mutedf.
There is a little extra tidying up with local variable names or converting code to use Mutedf format.
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.
Without fixing all ColorScheme.Gray and ColorScheme.Grayf usage in this pull request, golangci-lint throws errors for using deprecated functions.
As that code should be replaced within github/cli#833, I'm removing the deprecation indicator for now to get this PR passing.
This commit covers testing around the new ColorScheme.Muted logic based on various situations to gain confidence we get the accessible colors expected when enabled.
Additionally, this commit includes a small change to the existing 8-bit color logic to standardize on the same reset sequence for testing purposes. Essentially, `ESC[m` and `ESC[0m` are equivalent but this inconsistency with our other libraries makes setting up tests a little extra confusing and difficult.
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.
The function enableVirtualTerminalProcessing must return an error if
virtual terminal processing (only applicable on Windows) was not
enabled, otherwise we assume that the terminal supports both 256-color
and truecolor.
We have been erroneously assuming that all non-Windows terminals are
256-color and sending escape sequences to those that cannot intepret
them. This led to some parts of Survey prompts being invisible on old
terminals.
Regressed in be4b392530
This commit replaces `os.Setenv` with `t.Setenv` in tests. The
environment variable is automatically restored to its original value
when the test and all its subtests complete.
Reference: https://pkg.go.dev/testing#T.Setenv
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
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.
