Terminals should generate the 256-color palette

Original Article ↗ Hacker News Discussion ↗

Proposal and Rationale

  • Thread discusses the idea: terminals should auto‑generate the 256‑color palette from the user’s 16 base colors so everything respects the terminal theme while still getting “rich” color.
  • Some like it immediately: it would make many legacy tools look better “for free” and keep color customization centralized in the terminal instead of per‑app.
  • Variants suggested: do it in 24‑bit space, use LUTs to map 16 colors into a perceptual 256 palette, offer quantization sliders, and make the feature configurable via terminal settings or environment variables.

Concerns About Breaking Expectations

  • Strong pushback from people who design color schemes and TUIs that rely on the standard xterm 256 palette being fixed (indices 16–255).
  • They argue that today they can ship one 256‑color scheme and know that “color 146” will always look approximately the same; dynamic generation would destroy that guarantee.
  • Several insist the feature must be opt‑in or behind a new control code; otherwise existing themes and apps will become “double‑adjusted” and ugly.

User Control vs App/Theme Control

  • Repeated complaints about CLIs/TUIs overriding terminal colors with hard‑coded palettes or using colors outside the basic 16, forcing users to reconfigure every app.
  • Many prefer terminal‑level control and simple, semantic color use (e.g., few colors, mostly for emphasis/errors) over elaborate, app‑specific styling.
  • A subset explicitly dislike “rainbow TUIs” and compare the situation to accessibility problems on the web.

Accessibility and Contrast

  • Multiple comments note dark blue on black as effectively unreadable; users routinely change “blue” in their terminal or complain about tools that hardcode it.
  • Colorblind and visually impaired users report poor contrast in many themes; some use tooling/AI to derive high‑contrast variants from existing schemes.

Truecolor vs 256‑Color Palettes

  • Some say: just use 24‑bit “truecolor” and skip palettes.
  • Others echo the article’s downsides: per‑app config, no global light/dark switching, longer escape codes, and less universal support.
  • For many theme authors, the fixed 256 palette is the sweet spot: more colors than 16, but still predictable and centrally themed.

Semantic/Role-Based Coloring

  • Several propose a different direction: semantic/role‑based styles (ERROR, WARNING, HIGHLIGHT, etc.) instead of raw color indices.
  • Ideas include new SGR escape codes or extended modes that let the terminal map roles to actual colors, backgrounds, and font attributes per user theme.

Broader Terminal / GUI / Legacy Discussion

  • Side threads debate why we still use VT220‑style terminals at all, versus richer GUIs or notebook‑style REPLs.
  • Plan 9 / 9front is cited as an example of a text‑centric but non‑VT terminal world; others argue text terminals persist because they’re scriptable, composable, and work well over slow/remote links.

Images, HDR, and Miscellaneous

  • Some advocate for image or framebuffer support in terminals (e.g., existing Kitty protocol, Sixel/ReGIS) to enable notebook‑like experiences.
  • Brief tangent on HDR and color science, arguing that traditional sRGB #fff is limited and HDR would need different color models.
  • Concrete adoption: at least one popular macOS terminal and Ghostty have already implemented palette‑generation variants, generally behind options.