tea.Println content bypasses color-profile downsampling — NO_COLOR and low-color terminals get full-color scrollback

[dmotylev]

Describe the bug

The cell renderer downsamples View content to the detected color profile, but content delivered through tea.Println / Program.Println reaches the terminal verbatim. Under NO_COLOR=1 (or a 16-color/ascii profile) the live view obeys while every line committed to scrollback keeps its original colors.

Setup

• bubbletea v2.0.7 (charm.land/bubbletea/v2), Go 1.26.4, darwin/arm64
• Reproduces on any terminal; captures below are from a PTY via script

To reproduce

package main

import (
	"fmt"
	"os"
	"time"

	tea "charm.land/bubbletea/v2"
)

const red = "\x1b[31mred\x1b[m"

type model struct{}

type doneMsg struct{}

func (m model) Init() tea.Cmd {
	return tea.Batch(
		tea.Println("println: "+red),
		tea.Tick(300*time.Millisecond, func(time.Time) tea.Msg { return doneMsg{} }),
	)
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	if _, ok := msg.(doneMsg); ok {
		return m, tea.Quit
	}
	return m, nil
}

func (m model) View() tea.View { return tea.NewView("view: " + red) }

func main() {
	if _, err := tea.NewProgram(model{}, tea.WithInput(nil)).Run(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

go build -o repro .
script -q out.txt sh -c 'stty rows 24 cols 80; NO_COLOR=1 ./repro'

Observed (NO_COLOR=1, escapes made visible)

println: <ESC>[31mred<ESC>[m      <- Println path: color survives
view: red                          <- View path: correctly downsampled

Control run without NO_COLOR renders both red, as expected.

Expected

Both paths obey the same profile: colorprofile.Detect(p.output, p.environ) already runs at startup (tea.go) and cursedRenderer holds the result in s.profile.

Where it happens

cursedRenderer.insertAbove (cursed_renderer.go:707, v2.0.7) splits the queued string into lines and writes them straight to s.w — no ConvertStyle/profile pass — while regular frames are converted per cell at render time. ultraviolet.TerminalScreen.InsertAbove (terminal_screen.go:733) has the same shape: it takes content verbatim even though the screen carries a profile field and a SetColorProfile method.

Suggested fix

In insertAbove, pass each line through the already-available profile before writing, e.g.

var conv strings.Builder
_, _ = (&colorprofile.Writer{Forward: &conv, Profile: s.profile}).WriteString(line)
sb.WriteString(conv.String())

(or convert once when the string is enqueued in printLines). The same applies to ultraviolet's TerminalScreen.InsertAbove — happy to split this into a second issue there if you prefer to track it per-repo.

Workaround

Callers can downsample before calling Println:

profile := colorprofile.Detect(out, os.Environ()) // same detection the program runs
var sb strings.Builder
_, _ = (&colorprofile.Writer{Forward: &sb, Profile: profile}).WriteString(block)
p.Println(sb.String())

Context

Found while building a docker buildx-style progress renderer for mage builds, which commits finished subtrees to scrollback via Program.Println — under NO_COLOR=1 the live tree went monochrome while every committed block stayed in full color.

[truffle-dev]

Still reproduces at HEAD (fc707bb). The write path moved a little since v2.0.7 but the shape is identical: insertAbove (cursed_renderer.go:707) builds the scroll/insert sequence and appends each line untouched — the loop at 745-749 writes line verbatim, then 757 does io.WriteString(s.w, sb.String()) straight to the raw writer, skipping s.scr. Normal frames go through s.scr (a *uv.TerminalRenderer) which carries the profile via SetColorProfile (596/614) and converts per cell. So Println sidesteps the one place the downsample happens. Matches your read.

On "split a second ultraviolet issue?" — I don't think you need to. insertAbove never routes through ultraviolet's InsertAbove; it hand-rolls the ANSI and writes to s.w directly, and s.scr is a TerminalRenderer, not the TerminalScreen.InsertAbove you flagged. The two paths are independent, so a fix here won't be shadowed or duplicated by an upstream change, and the ultraviolet site isn't reached by Println on the current renderer. The fix belongs right where you put it.

Your suggested patch still applies cleanly — s.profile is live on the renderer (cursed_renderer.go:28), so routing each line through a &colorprofile.Writer{Forward: ..., Profile: s.profile} before the sb.WriteString(line) at 746 is a drop-in. Converting once when the string is enqueued works too and skips the per-line builder churn.