fix(ui): honor color settings in interactive prompt themes (#9999)

[JamBalaya56562]

Problem

Reported in discussion #9999: the interactive mise use tool picker (and other demand-based prompts) ignores color settings. On light terminals the default theme is unreadable, and color=false / NO_COLOR have no effect on the prompt styling.

Root cause

Interactive prompts use the demand crate. Its own Theme::default() already checks console::colors_enabled_stderr() and returns an unstyled Theme::new() when colors are disabled:

// demand-2.0.2/src/theme.rs
impl Default for Theme {
    fn default() -> Self {
        if console::colors_enabled_stderr() { Theme::charm() } else { Theme::new() }
    }
}

But mise's src/ui/theme.rs::get_theme() skipped that check and constructed a colored theme (charm() / base16() / …) directly, so the raw ColorSpec values were always emitted regardless of color=false / NO_COLOR / CLICOLOR=0 (all of which already set colors_enabled_stderr(false) in src/config/settings.rs).

Changes

• Honor disabled colors: get_theme() now returns Theme::new() (the same unstyled theme demand uses for its default) when colors_enabled_stderr() is false. This fixes every get_theme() call site (mise use, mise run task selection, mise search, mise set, mise upgrade, prompts) at once.
• Light-terminal auto-detection: added a color_theme = "auto" option, which is also the new behavior of the default "default". It detects a light background via the COLORFGBG env var and picks base16 for readability, otherwise charm. Explicit charm keeps the previous fixed dark theme (no auto-detection). OSC 11 terminal queries are intentionally not used (they can hang / corrupt output).
• Tests: selection logic is split into pure helpers (select_theme, colorfgbg_is_light) so both the colored and unstyled branches can be unit-tested without depending on the global color state (the test harness forces colors off globally).
• Docs / schema: updated settings.toml (enum + docs) and regenerated schema/mise.json via mise run render:schema.

Behavior change note

When color_theme is left at its default, mise now auto-detects a light terminal via COLORFGBG and switches to base16. Terminals without COLORFGBG, and any explicit theme value, behave as before. default is documented as an alias for auto; set charm to force the previous dark theme.

Testing

• cargo test --bin mise ui::theme:: → 5 passed.
• cargo build → clean (pre-existing warnings only).
• Manual: MISE_COLOR=0 mise use / NO_COLOR=1 mise use produce no ANSI styling; COLORFGBG="0;15" MISE_COLOR_THEME=auto mise use renders the readable light theme.

Relates to the earlier abandoned draft #10009 (closed by its author without landing); this takes a simpler approach by reusing demand's own Theme::new() instead of manually clearing fields.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces automatic terminal background color detection to dynamically select an appropriate theme (using a light-friendly theme like base16 on light terminals, and charm on dark terminals) based on the COLORFGBG environment variable. It updates the JSON schema, settings documentation, and theme selection logic in Rust, and adds comprehensive unit tests for the new behavior. There are no review comments, and I have no feedback to provide.

[greptile-apps]

Greptile Summary

This PR fixes interactive prompts ignoring color settings by making get_theme() return an unstyled Theme::new() when colors are disabled, and adds a best-effort light-terminal auto-detection path via COLORFGBG. The logic is cleanly split into pure, well-tested helpers (select_theme, colorfgbg_is_light) that cover all branches including the disabled-colors path that the test harness previously couldn't reach through get_theme() directly.

• Color-disable fix: select_theme now short-circuits to Theme::new() when colors_enabled_stderr() is false, mirroring demand::Theme::default()'s own behavior and fixing every call site at once.
• Light-terminal auto-detection: "auto" / "default" now check COLORFGBG and pick base16 for readability on light terminals, falling back to charm (the previous unconditional behavior) when the variable is absent or unparseable.
• Settings/schema: "auto" added to the enum; settings.toml docs and generated schema/mise.json are updated and consistent with the new aliasing (auto/default together, not with charm).

Confidence Score: 5/5

Safe to merge — changes are isolated to theme selection logic with no effect on correctness of any other subsystem.

The fix is a small, well-contained change to a UI helper: the disabled-colors short-circuit is straightforward and matches demand's own behavior, the COLORFGBG detection is best-effort with a safe false default, and the pure-helper refactor makes the branches directly testable. All changed paths are covered by the five new unit tests. The behavior delta for existing users (default theme) is zero unless COLORFGBG is set to a light-background value.

No files require special attention.

Important Files Changed

Filename	Overview
src/ui/theme.rs	Core logic change: adds color-disable check, light-background auto-detection via COLORFGBG, and pure helper functions with unit tests covering all branches
settings.toml	Adds "auto" to the enum, updates description and docs to correctly reflect auto/default aliasing and the new auto-detection behavior
schema/mise.json	Generated schema updated to match settings.toml: adds "auto" to enum and corrects the short description to auto/default grouping

_{Reviews (5): Last reviewed commit: "fix(ui): honor color settings in interac..." | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.