You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature: use the built-in color themes in non-powerline mode (+ font-safe separator fallback) #604
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.
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.
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.
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.
Activity
feat(themes): apply color themes in regular (non-powerline) mode, fg-…
fix(powerline): fall back to a plain | separator when no Powerline fo…
feat(themes): apply color themes in regular (non-powerline) mode, fg-…
vishnujayvel commentedon Oct 12, 2026
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.
axisrow commentedon Oct 12, 2026
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 andCCSTATUSLINE_FONT_CHECK=skipas 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.
axisrow commentedon Oct 15, 2026
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 shortNFform, 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.