fix(tui): stop clobbering theme mode with auto-detected value on every render event#21011
fix(tui): stop clobbering theme mode with auto-detected value on every render event#21011kevinWangSheng wants to merge 1 commit into
Conversation
…y render event
apply() was calling kv.set("theme_mode") on every THEME_MODE renderer event,
persisting the auto-detected mode to KV. On the next launch, kv.get("theme_mode")
would return this stale value even if the system theme had changed, overriding
the freshly detected props.mode.
Fix: remove the kv.set from apply() so auto-detection is never persisted.
On init, drop the kv.get("theme_mode") fallback entirely — if the user has an
explicit lock (theme_mode_lock), use it; otherwise use props.mode which is the
live system detection from getTerminalBackgroundColor(). Explicit pin/lock
behavior is unaffected since pin() still writes theme_mode_lock.
Closes anomalyco#20926
|
The following comment was made by an LLM, it may be inaccurate: The search results show only the current PR (21011) and one related PR from 2024 (15612) that added the initial theme_mode config feature, which is not a duplicate but a related earlier feature. No duplicate PRs found |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #20926
Type of change
What does this PR do?
apply()was callingkv.set("theme_mode", mode)on everyTHEME_MODErenderer event, persisting the auto-detected value to KV. On the next launch,kv.get("theme_mode")returned this stale value and overrodeprops.mode(the freshly queried system background color), so the theme stayed stuck on whichever mode was last detected — even if the system had switched.Two changes:
kv.set("theme_mode", mode)fromapply()— auto-detection should never be persisted; only an explicit user lock should be.kv.get("theme_mode")fallback in init — on startup, if the user hasn't pinned a lock (theme_mode_lock), useprops.modedirectly (live system detection fromgetTerminalBackgroundColor()). This clears any stale KV value left over from the old behavior.Explicit lock/unlock behavior is unaffected:
pin()still writestheme_mode_lock, andlock ?? props.modein the init correctly picks it up.How did you verify your code works?
bun run typecheck --filter=opencodepassesdraft.mode = props.modenow comes directly from the terminal background color query — stale KV values can no longer interfereapply()/ renderer event path no longer touches KV at all, so repeated theme events during a session won't overwrite the next session's startup modeScreenshots / recordings
N/A — internal state fix
Checklist