fix(tui): stop clobbering theme mode with auto-detected value on every render event#21011
Open
kevinWangSheng wants to merge 1 commit intoanomalyco:devfrom
Open
fix(tui): stop clobbering theme mode with auto-detected value on every render event#21011kevinWangSheng wants to merge 1 commit intoanomalyco:devfrom
kevinWangSheng wants to merge 1 commit intoanomalyco:devfrom
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
Contributor
|
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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