From 5599f304376fa792f9c94e5182d1cb144c716a4e Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Tue, 16 Jun 2026 06:27:20 -0500 Subject: chore(todo): drop the false-alarm empty-preview-packages task Craig confirmed alert does have elements, so the dropped-packages task was a false alarm. --- todo.org | 2 -- 1 file changed, 2 deletions(-) diff --git a/todo.org b/todo.org index 500f151f0..43e06948f 100644 --- a/todo.org +++ b/todo.org @@ -46,8 +46,6 @@ Tags are additive. For example, a small wrong-behavior fix can be * Emacs Open Work ** TODO [#C] theme-studio: move the "clear palette" button :feature:studio:next: The clear-palette button is too easy to hit by accident (then re-import the JSON to recover). It currently rides with the update-color and palette-generation controls, not with the palette columns. Move it to be left-aligned at the same vertical level as the color-column names. Layout/CSS change in the palette area (app.js / styles.css); visual, so verify by eye. From the roam inbox 2026-06-16. -** TODO [#C] theme-studio: drop dropdown packages that have no preview elements :feature:studio:next: -"alert" shows nothing useful when selected, and any other such package should also be dropped from the assignment-view dropdown. Investigation 2026-06-16: alert DOES have 6 faces (alert-*-face), so "no elements" is not about the faces table. The preview is keyed — APPS[app].preview indexes PACKAGE_PREVIEWS (app.js), which has 6 dedicated renderers (autodim, org, dashboard, flycheck, erc, pearl); every other app falls back to genericPreview (face names in their own colors). So a bare "no dedicated renderer" rule would drop ~47 of 53 apps, which is clearly not the intent. Need from Craig: the exact criterion for "no elements" (and ideally a quick look at what alert's preview actually renders), then filter buildViewSel to exclude the named set, mirroring the appViewKeysSorted pattern. From the roam inbox 2026-06-16. ** TODO [#C] buffer-differs save prompt: 4-way yes/no/diff/cancel :feature:next: The "buffer differs from file" confirmation currently gives only yes/no. Craig wants a 4-way choice with explicit consequences: yes (be explicit it overwrites), no (be explicit it discards this action and continues), diff (show a graphical difftastic diff, then return to this prompt), cancel (stop the action, leave the buffer untouched). Needs the exact prompt identified first (which save/overwrite path raises "buffer differs") and a design for the diff-then-return loop. difftastic + cj/diff-buffer-with-file infrastructure already exist. From the roam inbox 2026-06-16. ** DOING [#B] Dashboard theming broken: font-lock strips faces; items + icons :bug: -- cgit v1.2.3