This commit reverts the previous color changes in the prompt UI. While color highlighting could potentially improve the visual appealing of the prompt
using the existing color library (mguz/ansi) with the prompt library (AlecAivazis/survey) caused unintended side effects.
It reset the bold text style for the selected option. We decide to that
bold text style would have a higher priority than the color text ,for
three reasons:
1. To maintain consistency with other prompts in the UI and prioritize accessibility
2. While color can enhance the user experience, according to Primer Design Guidelines, color should not be relied upon to convey essential information.
3. visual indicator of the selected option, especially crucial when dealing with long PR titles or branch names.
As a future improvement, we may consider a separate issue or PR to address the color library issue and explore controlled color usage in prompts. This could potentially allow for more nuanced visual differentiation while avoiding unintended style resets.
Co-authored-by: Kynan Ware <47394200+BagToad@users.noreply.github.com>
You need to know exact `baseRefOid` so you could show correct diff.
`baseRefName` is not enough sometimes because branch from which PR was
forked might have changes already.
Example usage:
```
gh pr view --json headRefName,headRefOid,number,baseRefName,baseRefOid,reviewDecision
```
Improve the interactive PR selection UI by
- prefix the PR number with hashcode #
- perserve the text formatting (bold) upon an option is hovered
- add the PR head label
Technical changes:
- Replace \033[0m with \033[39m for maintaining text formatting
IsEnterprise currently returns `true` when `IsTenancy` returns true. We
prefer that this behavior is orthogonal. This commit adds failing tests to
the instances where IsEnterprise should not behave the same as IsTenancy.
These test cases are expected to pass with the inclusion of the coming
improvements to go-gh to handle the orthogonality of IsEnterprise and
IsTenancy.
Currently, the prompter doesn't enforce the requirement of a title for PR
and Issue creation. However, that creates the UX where a user can enter a
blank title, spend time filling out a detailed body, then fail to create
the issue or pr when the request is sent to the api because the title is
blank. This attempts to handle that before sending a request to the api,
enforcing that, when prompting, the title of an issue is not blank.
While the `state` field corresponds 1:1 with different GitHub Actions
states, the `bucket` field is an abstraction of the CLI that lacked
documentation. This both adds documentation about the existence of the
`bucket` field and enumerates the possible values.
With the upcoming migration from v1 project to v2 projects, we'd like the
language in our documentation to align with v2 project language. In v2,
projects are referred to by `title` and not `name`, though they are
functionally equivalent under the hood for the CLI
Found with
rg '(^ | \t|\t )' -g '*.go' -g '!*_test.go'
Mixed indent exceptions:
- wrapped long list items with extra 2-space indent
- code snippets using space indent
- commented code lines having "\t*// \t+" prefix
