diff options
| -rw-r--r-- | todo.org | 3 |
1 files changed, 2 insertions, 1 deletions
@@ -46,7 +46,8 @@ Tags are additive. For example, a small wrong-behavior fix can be * Emacs Open Work ** TODO [#A] theme-studio: deploy-wip button on the browser page :feature:studio:next: Add a button on the theme-studio page that runs the make deploy-wip target locally (build WIP.json into the theme, live-reload the daemon). The page is served from file://, so the browser can't run make directly. Needs a local bridge: a tiny localhost helper the button POSTs to, or a watched trigger file the page writes. Pick the mechanism before building. From the roam inbox 2026-06-15. -** TODO [#A] theme-studio: cannot reassign fg color :bug:studio:next: +** VERIFY [#A] theme-studio: cannot reassign fg color :bug:studio:next: +Needs from Craig: the exact repro (palette JSON + click sequence, or a quick screen capture). I traced it and couldn't reproduce from the code: updateColor (the "update selected" path) already excludes the selected entry from its uniqueness check (j!==i), and the fg/bg chips are selectable — paletteChip wires d.onclick -> selectColor(i), with the lock only blocking removal, not selection. The "already exists" wording is addColor's message, which is only reached via applyEdit when selectedIdx is null (i.e. no chip selected). So the trigger is a state I can't see statically — selection getting lost before "update", or a second entry already named "fg". With the precise steps I can pin it; I won't guess-patch the palette-update path on an [#A] bug since a wrong fix there corrupts themes. Selecting the fg tile, changing its value, and clicking update errors that an fg already exists instead of updating it. The update path treats a reassign as an add. From the roam inbox. ** TODO [#A] calendar-sync drops final occurrences, resurrects cancelled meetings :bug:solo:next: :PROPERTIES: |