Honor CLICOLOR_FORCE when stdout isn't a TTY

[umekikazuya]

Related issue: #968
Related discussion: #943 - Same underlying need, approached from the flag side.

I have a working patch and would like a read on the approach before proposing it.

Problem

When stdout isn't a terminal, glow replaces the requested style with notty and there is no way to override that from the environment. CLICOLOR_FORCE=1 has no effect, so any caller that captures glow's output but can render ANSI itself gets plain text instead.

Concrete cases where this comes up:

• fzf previews — fzf --preview 'glow {}'. The preview pane is a pipe from the child's perspective, so markdown markers show up verbatim.
• CI logs — GitHub Actions renders ANSI, but glow README.md in a workflow can't produce it.
• Embedding in other CLI tools — the case in Feature request: support --color=always / CLICOLOR_FORCE for non-TTY rendering (e.g. embedded in AI coding tools) #968, where glow runs inside a tool that displays its stdout.

Passing --style explicitly works around it today, but that requires knowing about the interaction, and it means choosing a fixed style rather than letting glow decide.

Root cause

main.go:

isTerminal := term.IsTerminal(int(os.Stdout.Fd()))
if !isTerminal && !cmd.Flags().Changed("style") {
    style = "notty"
}

The style is swapped out before rendering, so nothing downstream can bring color back. None of NO_COLOR, CLICOLOR or CLICOLOR_FORCE are read anywhere in the codebase.

Proposed change

Use charmbracelet/colorprofile for the decision instead of a bare isatty check. It's already in glow's dependency graph (currently indirect), and it's the org's own implementation of these conventions — so this follows the existing Charm mechanism rather than adding a parallel one.

-// We want to use a special no-TTY style, when stdout is not a terminal
-// and there was no specific style passed by arg
-if !isTerminal && !cmd.Flags().Changed("style") {
-    style = "notty"
+profile = colorprofile.Detect(os.Stdout, os.Environ())
+
+// We want to use a special no-TTY style, when the output can't display
+// anything but plain text and there was no specific style passed by arg
+if profile <= colorprofile.NoTTY && !cmd.Flags().Changed("style") {
+    style = styles.NoTTYStyle
 }

and write the rendered output through a colorprofile.Writer, so downsampling is the profile's job rather than hand-rolled logic:

if profile > colorprofile.NoTTY {
    w = &colorprofile.Writer{Forward: w, Profile: profile}
}

glamour v2 emits ANSI unconditionally — it has no colorprofile references — so applying the profile is the caller's responsibility. Right now glow doesn't, which is also why glow -s dark file.md sends 256-color sequences to a 16-color terminal.

What doesn't change

This is the part I'd most like checked:

• Default piped output. With no color env vars set, profile is NoTTY, the notty style is still selected, and the bytes are identical to today.
• Terminal width detection. isTerminal was doing two unrelated jobs. Only style selection changes; term.GetSize still uses isTerminal.
• glow -s dark file.md | cat. The writer is deliberately skipped when there's no color support, so this existing escape hatch keeps working. Applying the writer there would have stripped the colors and changed current behavior.
• --style handling. The cmd.Flags().Changed("style") check is untouched.

Known gap

That last compatibility choice has a consequence worth naming: NO_COLOR=1 glow -s dark file.md | cat still emits color. colorprofile maps both "NO_COLOR is set" and "output is a plain pipe" to NoTTY, so the profile alone can't distinguish them, and the guard that protects the escape hatch also skips stripping here.

To be clear this is pre-existing rather than introduced here — I verified that case produces identical output on master and on the branch.

Closing it would mean reading NO_COLOR directly, and deciding whether it should override an explicit --style. I left it out to keep the change additive, but happy to include it if you'd rather have full NO_COLOR compliance in one go.

Tests

I've written tests that render through the real CLI path and assert the actual bytes: NoTTY keeps # Hi and **bold** verbatim with no escape sequences, ANSI output has no \x1b[38;5; sequences left, ANSI256 keeps them.

Questions

1. Is this approach acceptable, or would you rather glow not grow environment-variable behavior here?
2. Would a --color=always|auto|never flag (option A in Feature request: support --color=always / CLICOLOR_FORCE for non-TTY rendering (e.g. embedded in AI coding tools) #968) be wanted as a follow-up? It'd be a thin layer over the detected profile. colorprofile also already honors TTY_FORCE=1, which covers the --force-tty idea from that issue without a new flag.
3. Unrelated but adjacent: the config-file style: value is also discarded when piping, because the check is cmd.Flags().Changed("style") and doesn't see config values. Is that intentional, or worth fixing separately?

The patch is on a branch if you want to look at the actual change before deciding — compare view. Not opening it as a PR yet, per CONTRIBUTING.md. Happy to do that once there's a direction.