Skip to content

Feature: use the built-in color themes in non-powerline mode (+ font-safe separator fallback) #604

Open

Description

@axisrow

Feature: apply the built-in color themes in regular (non-powerline) mode

POWERLINE_THEMES (src/utils/colors.ts) ships 10 curated themes — Nord, Nord Aurora, Monokai, Solarized, Minimal, Dracula, Catppuccin, Gruvbox, One Dark, Tokyo Night — each calibrated for ansi16 / ansi256 / truecolor. They are only honored by the powerline renderer, though: in regular mode the coloring is strictly per-widget and manual, so there is no way to get a coherent palette without hand-picking every widget color in the ColorMenu.

Proposal

Make the theme catalog usable in regular mode, foreground-only:

  • honor powerline.theme (or introduce a top-level theme setting) in the regular renderer: cycle the theme's fg colors across widgets — or map them by widget category — without backgrounds or arrows;
  • existing per-widget colors keep working as explicit overrides on top of the theme.

This gives users a curated, consistent look in the default mode with a single setting, and reuses the theme definitions that are already shipped and calibrated for all three color levels.

Related bug: separator glyph renders as mojibake without a Nerd Font

The default powerline separator is the private-use-area glyph U+E0B0 (人力资源 arrow). checkPowerlineFonts() (src/utils/powerline.ts) can detect font availability and getPowerlineStatusMessage() has a ready "✗ Powerline fonts not detected - some symbols may not display correctly" message, but:

  • that warning only surfaces in the TUI setup flow; enabling powerline via config/CLI without a Nerd Font produces garbage glyphs in the rendered status line with no hint of the cause;
  • there is no render-time fallback.

Suggestion: if font detection fails and the configured separator is a private-use-area glyph, fall back to a plain separator (" | " or " ") at render time, and/or surface the existing status message once.

Environment: ccstatusline 2.2.30, macOS, terminal without Nerd Font.

Activity

  1. vishnujayvel commented on Oct 12, 2026

    @vishnujayvel
    Contributor

    For the separator fallback part of this issue, which behavior would you prefer?

    A local font scan does not establish which font a remote terminal has selected. Replacing glyphs after a negative scan could therefore change an already-working status line. Would you prefer an ASCII fallback that users explicitly enable, a warning while preserving their configured glyphs, or another approach?

    I’m holding this behavior change pending your preference. This question is separate from applying color themes in regular mode.

  2. axisrow commented on Oct 12, 2026

    @axisrow
    ContributorAuthor

    For the separator fallback this is up to you.

    I've opened #718 with my take on this: a render-time font-safe pass (powerline separators/caps, regular-mode separator characters and the default separator) that degrades anything not detected-safe to a plain |, with the detection result cached per process and CCSTATUSLINE_FONT_CHECK=skip as an escape hatch for when the local scan is wrong (e.g. remote terminals).

    @vishnujayvel — feel free to pick whichever works better for you: cherry-pick from #718, or open your own competing PR. Either way is fine on my side.

  3. axisrow commented on Oct 15, 2026

    @axisrow
    ContributorAuthor

    Heads-up for the font-safe separator fallback proposed here: the detection it would key on currently reports a capable font as missing for Nerd Fonts v3 layouts (spaceless names like JetBrainsMonoNerdFont-Regular.ttf, the short NF form, fonts in subfolders). A fallback built on it would turn working arrows into | for exactly those setups — the fork hit this in practice. Repro and details in #738, fix in #739.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions