Does this really "fix https://github.com/github/cli/issues/830"? Maybe it won't close the issue because it's cross org but it seems to me we need to either merge this to main and release or point cli/cli to this commit right? Is there any other work required beyond that?

Does this really "fix github/cli#830"?

No, good call out; I've updated this to "relates" because your next comment is on point: we need to start using it ...

Maybe it won't close the issue because it's cross org but it seems to me we need to either merge this to main and release or point cli/cli to this commit right? Is there any other work required beyond that?

... I think we have potentially 3 choices of how to move forward:

1. Merge this into default branch and release it

   If we did this now as-is, then any markdown package user who wanted to update cli/go-gh would be required to do a light/moderate bit of heavy lifting to switch over to cli/glamour.

   They will also have to undo it later when we finally contribute our fork changes upstream and remove cli/glamour; not a great experience.

2. Point cli/cli to this commit

   This would allow us begin using it without affecting other cli/go-gh users.

   It also means that we have to be vigilant about other cli/go-gh changes going into the default branch and keeping accessible-colors up to date until we can get the upstream changes accepted.

3. Move accessible-colors work under x/markdown package separate of markdown

   Your comment about about marking or signaling that functions are experimental reminded me of golang.org/x of charmbracelet/x.

   The idea being that this could:

   1. Merge this into the default branch and release
   2. Avoid impacting cli/go-gh users of markdown
   3. Reduce some of our toil iterating on cli/cli and cli/go-gh while getting changes accepted upstream
   4. Communicate status of these new changes, maybe even help to get feedback from those interested who pick up on them

Post-discussion with Will about the above points

1. We think cli/glamour changes should go into upstream before merging accessible-colors to avoid disrupting GitHub CLI extension authors

   • Add term renderer option for chroma formatter charmbracelet/glamour#395

2. We think expanding color capabilities for GitHub CLI and CLI is at odds with accessibility package and want to do the following

   • Rename the accessibility package to color

3. We want to ensure these changes are understood to be experimental and will do the following

   • Add in-line comments about the experimental status of the accessible color logic
   • Move the color package to x/color to communicate experimental status

Reasoning

When our efforts to build a more accessible GitHub CLI experience started, we didn't know the full scope of how it would play out in cli/cli and cli/go-gh changes. We knew there were concerns around colors in general, colors in markdown, and screen readers working with prompting. As we have made progress, the accessibility package feels the wrong way to organize this new behavior versus what it is affecting.

The question is where does this live?

• config: underlying gh config and guts of GitHub CLI configuration
• prompter: interactive user prompting
• term: terminal environment and capability handling

The idea of a new color package was motivating bringing GitHub CLI color handling logic out of cli/cli and into cli/go-gh while expanding on ideas from Primer Design System and color roles.

Testing these changes against upstream charmbracelet/glamour contribution

@williammartin : I just finished building cli/cli locally against a modified version of this branch with charmbracelet/glamour#395 contributions to verify the work within accessible-colors. Once this contribution is merged, I'm confident we can switch off our fork and finish releasing these changes.

Is there anything else you'd like to see before finalizing review here?

Test Branch: https://github.com/cli/go-gh/tree/andyfeller/gh_accessible_colors_upstream
Test Repo: https://github.com/andyfeller/markdown-lorem-ipsum

Demonstrating non-codeblock accessible colors

In the following screenshot, the lefthand terminal displays the current gh markdown color behavior of 8-bit color with the righthand terminal using this branch's changes and displays 4-bit color:

The righthand terminal's markdown headers can now be modified through terminal preferences to render magenta as canary yellow:

Demonstrating codeblock accessible colors

In the following screenshot, the lefthand terminal displays the current gh markdown color behavior of 8-bit color with the righthand terminal using this branch's changes and displays 4-bit color:

The righthand terminal's codeblocks can now be modified through terminal preferences to render white as electric blue:

Adding a note that the upstream contribution has been merged but not released, so we could update this branch to merge into the default branch using upstream instead of merging back into accessible_colors using our fork.