Ensure codeblocks use accessible colors

[andyfeller]

This commit leverages cli fork of charmbracelet/glamour with enhancement for configuring chroma formatter.

It includes simple tests that enabling gh accessible features causes codeblocks to be downsampled to base 16 ANSI colors.

[andyfeller]

Looking back at the changes in the PR versus cli/cli#9821, I'm confirming the need to remove the replace and change all of the import statements to use our fork until we can get the changes accepted upstream.

[jtmcg]

Could you link the fork changes, @andyfeller? I'd find it helpful so we understand what this is introducing from the fork.

[jtmcg]

I find it really hard to tell what's different between this blob of output versus the one on line 96. That's why I added the human-grokkable format in the tests above these. I also find it a bit jarring that the output formats are different for these tests and would find value in their consistency. Perhaps codeblocks are different enough to justify it, but there may be value in pulling out a human-grokkable abstraction in these wantOuts

[andyfeller]

Completely get that 💯 as that was a consideration when I was writing the tests I choose to defer to seeing if someone would comment on. 👍

I can play around to see what this would look like for a more grokkable format but I suspect the extent of control characters is pretty significant. I don't know how much more grokkable it will be trying to reuse a bunch of placeholders but we can try.

[andyfeller]

Here's an example of what this would look like if we used the same approach of constants:

	reset                                            = "\x1b[0m"
	glamourLightCodeBlock_8bitRaisinBlackColorSeq    = "\x1b[38;5;235m"
	glamourLightCodeBlock_8bitVividTangerineColorSeq = "\x1b[38;5;210m"
	glamourLightCodeBlock_8bitJadeColorSeq           = "\x1b[38;5;35m"
	glamourLightCodeBlock_8bitCopperRoseColorSeq     = "\x1b[38;5;95m"

		{
			name: "when the light theme is selected, the codeblock renders using 8-bit colors",
			text: heredoc.Docf(`
				%[1]s%[1]s%[1]sgo
				fmt.Println("Hello, world!")
				%[1]s%[1]s%[1]s
			`, "`"),
			theme: "light",
			// wantOut: "\x1b[0m\x1b[38;5;235mfmt\x1b[0m\x1b[38;5;210m.\x1b[0m\x1b[38;5;35mPrintln\x1b[0m\x1b[38;5;210m(\x1b[0m\x1b[38;5;95m\"Hello, world!\"\x1b[0m\x1b[38;5;210m)\x1b[0m",
			wantOut: fmt.Sprintf("%[1]s%[2]sfmt%[1]s%[3]s.%[1]s%[2]sPrintln%[1]s%[3]s(%[1]s%[4]s\"Hello, world!\"%[1]s%[3]s)%[1]s", reset, glamourLightCodeBlock_8bitRaisinBlackColorSeq, glamourLightCodeBlock_8bitVividTangerineColorSeq, glamourLightCodeBlock_8bitCopperRoseColorSeq),
		},

[andyfeller]

I also think there is something weird going on with the test as I originally implemented the dark tests and it used different escape codes, however I think there is some flakiness with chroma between tests that it isn't using the appropriate theme.

Before introducing light test case, this was the result of dark without and with accessible colors:

wantOut: "\x1b[0m\x1b[38;5;251mfmt\x1b[0m\x1b[38;5;187m.\x1b[0m\x1b[38;5;42mPrintln\x1b[0m\x1b[38;5;187m(\x1b[0m\x1b[38;5;173m\"Hello, world!\"\x1b[0m\x1b[38;5;187m)\x1b[0m",

wantOut: "\x1b[0m\x1b[37mfmt\x1b[0m\x1b[37m.\x1b[0m\x1b[36mPrintln\x1b[0m\x1b[37m(\x1b[0m\x1b[33m\"Hello, world!\"\x1b[0m\x1b[37m)\x1b[0m",

After adding light test case before dark, this is the result:

wantOut: "\x1b[0m\x1b[38;5;235mfmt\x1b[0m\x1b[38;5;210m.\x1b[0m\x1b[38;5;35mPrintln\x1b[0m\x1b[38;5;210m(\x1b[0m\x1b[38;5;95m\"Hello, world!\"\x1b[0m\x1b[38;5;210m)\x1b[0m",

wantOut: "\x1b[0m\x1b[30mfmt\x1b[0m\x1b[33m.\x1b[0m\x1b[36mPrintln\x1b[0m\x1b[33m(\x1b[0m\x1b[90m\"Hello, world!\"\x1b[0m\x1b[33m)\x1b[0m",

Going to step through the debugger a bit to see what's going on.

[jtmcg]

Clever, but I really don't like how this reads... I find it pretty confusing given this is returning a glamour.TermRendererOption. I guess it's a function of this call signature, but that requires implementation level knowledge of glamour to understand this code.

I think I might prefer to abstract this closure out to something separate, so we end up with something like

Suggested change

	// Applying multiple glamour.TermRendererOption here requires a wrapper that applies each
	// within glamour.NewTermRenderer() in Render() below.
	stylesOption := glamour.WithStyles(AccessibleStyleConfig(theme))
	chromaOption := glamour.WithChromaFormatter("terminal16")
	return func(tr *glamour.TermRenderer) error {
	if err := stylesOption(tr); err != nil {
	return err
	}
	if err := chromaOption(tr); err != nil {
	return err
	}
	return nil
	}
	return AccessibleStyles(theme)
	// in the accessibility dir
	func AccessibleStyles(theme string) glamour.TermRendererOption {
	// Applying multiple glamour.TermRendererOption here requires a wrapper that applies each
	// within glamour.NewTermRenderer() in Render() below.
	stylesOption := glamour.WithStyles(AccessibleStyleConfig(theme))
	chromaOption := glamour.WithChromaFormatter("terminal16")
	return func(tr *glamour.TermRenderer) error {
	if err := stylesOption(tr); err != nil {
	return err
	}
	if err := chromaOption(tr); err != nil {
	return err
	}
	return nil
	}
	}

That way, we're separating the logic of "this is how you build the accessible theme using our implementation" from "select the right theme to use"

[andyfeller]

Clever, but I really don't like how this reads... I find it pretty confusing given this is returning a glamour.TermRendererOption. I guess it's a function of this call signature, but that requires implementation level knowledge of glamour to understand this code.

I think I might prefer to abstract this closure out to something separate, so we end up with something like

That way, we're separating the logic of "this is how you build the accessible theme using our implementation" from "select the right theme to use"

I was definitely conflicted in the implementation because of where / how we were applying the accessible theme in WithTheme versus in Render where this would allow us to have separate TermRendererOption that would be cleaner.

That said, I think at some level the reader digging into this has to understand glamour as long as its the dependency we use here.

Do you think further abstracting this could create a different type of confusion for reasoning about this behavior?

[andyfeller]

Going to close this PR for the moment because there is a bit more work to do with changing this to use our fork of glamour with import paths.

Will continue responding to comments in the mean time. 👍