Skip to content

feat(tui): add auto theme mode that follows system/terminal theme#21611

Open
ZhangWillThink wants to merge 1 commit intoanomalyco:devfrom
ZhangWillThink:feat/tui-auto-theme-mode
Open

feat(tui): add auto theme mode that follows system/terminal theme#21611
ZhangWillThink wants to merge 1 commit intoanomalyco:devfrom
ZhangWillThink:feat/tui-auto-theme-mode

Conversation

@ZhangWillThink
Copy link
Copy Markdown

@ZhangWillThink ZhangWillThink commented Apr 9, 2026

Issue for this PR

Related: #9697, #4464

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Replaces the two separate theme commands ("Toggle theme mode" + "Lock/Unlock theme mode") with a single cycling command that introduces a three-state scheme: auto → dark → light → auto.

In auto mode (the new default), the TUI follows the terminal's reported background color via the existing OSC 11 detection and renderer theme-change events. This infrastructure was already in place but wasn't exposed to users in a clean way — the previous UX required toggling + locking separately, which was confusing.

Key design decisions:

  • store.scheme ("auto" | "dark" | "light") = user preference. store.mode ("dark" | "light") = resolved actual mode. These are intentionally separate.
  • KV key theme_scheme stores the preference. On init, legacy theme_mode_lock entries are read as fallback for backward compat.
  • Existing locked()/lock()/unlock()/setMode() API preserved as thin wrappers so nothing breaks downstream.
  • Plugin API TuiTheme.mode() still returns the resolved "dark" | "light", unchanged.
  • No OS polling, no config file changes, no new dependencies. Just wiring up what was already there.

Difference from related PRs:

How did you verify your code works?

  • bun run typecheck passes across all 13 packages (via turbo)
  • Existing theme store tests pass: bun test test/cli/tui/theme-store.test.ts (5/5)
  • Manual testing: command palette shows "Theme mode: auto/dark/light", cycling works, auto mode follows terminal theme changes

Screenshots / recordings

Command palette cycling: The "Theme mode" command now shows the current scheme and cycles through auto → dark → light → auto on each selection.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@github-actions github-actions bot added the needs:compliance This means the issue will auto-close after 2 hours. label Apr 9, 2026
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 9, 2026

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate PRs Found

Based on the search results, there are potentially related PRs addressing similar theme functionality:

  1. PR feat(tui): add system dark/light mode matching #9719 - feat(tui): add system dark/light mode matching

  2. PR feat(tui): add theme_mode config to override terminal color detection #15612 - feat(tui): add theme_mode config to override terminal color detection

  3. PR fix(tui): allow theme mode override #20106 - fix(tui): allow theme mode override

These PRs all touch on TUI theme handling and automatic theme detection. You may want to review them to ensure PR #21611 doesn't duplicate efforts or conflicts with existing work.

@github-actions github-actions bot removed the needs:compliance This means the issue will auto-close after 2 hours. label Apr 9, 2026
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 9, 2026

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Replace the binary dark/light toggle with a three-state scheme
(auto | dark | light). In auto mode the TUI follows the terminal's
reported background color via OSC 11 and renderer events. Users can
still force dark or light through the command palette, which now
cycles: auto → dark → light → auto.

Backward compatible: legacy theme_mode_lock KV entries are migrated
on read, and the existing locked()/lock()/unlock()/setMode() API
surface is preserved as thin wrappers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant