diff options
| -rw-r--r-- | archive/task-archive.org | 2 | ||||
| -rw-r--r-- | assets/2026-07-15-velox-zbm-zfs-list-photo.jpg | bin | 0 -> 514227 bytes | |||
| -rw-r--r-- | assets/2026-07-19-settings-panel-scope-decisions.org | 15 | ||||
| -rw-r--r-- | assets/2026-07-31-agenda-json-api-contract.txt | 79 | ||||
| -rw-r--r-- | assets/2026-07-31-agenda-json-render-profile.txt | 55 | ||||
| -rw-r--r-- | assets/2026-07-31-agenda-json-window-refresh.txt | 53 | ||||
| -rw-r--r-- | assets/2026-08-13-velox-amd-board-swap-context.org | 5 | ||||
| -rw-r--r-- | assets/2026-08-13-velox-bios-boot-manager-photo.jpg | bin | 0 -> 135646 bytes | |||
| -rw-r--r-- | assets/2026-08-13-velox-bios-setup-utility-photo.jpg | bin | 0 -> 234084 bytes |
9 files changed, 208 insertions, 1 deletions
diff --git a/archive/task-archive.org b/archive/task-archive.org index f2edf58..0fb55c7 100644 --- a/archive/task-archive.org +++ b/archive/task-archive.org @@ -1664,7 +1664,7 @@ umount /mnt/be # 6. only once /boot shows a kernel: zpool export zroot && reboot #+end_src -Scope: only zroot/ROOT/default reverts; /home, /var, /media are separate datasets, untouched. After boot: =pacman -Syu= attended, confirm /boot holds vmlinuz-linux + initramfs before any shutdown. Full diagnosis: =inbox/PROCESSED-2026-07-15-0002-from-.emacs.d-velox-boot-failure-handoff.org=; ZBM photo: =inbox/PROCESSED-2026-07-15-0002-from-.emacs.d-PXL_20260715_043758976.jpg= (local on ratio; inbox is gitignored). +Scope: only zroot/ROOT/default reverts; /home, /var, /media are separate datasets, untouched. After boot: =pacman -Syu= attended, confirm /boot holds vmlinuz-linux + initramfs before any shutdown. Full diagnosis: =docs/design/2026-07-15-velox-boot-failure-handoff.org=; ZBM photo: =assets/2026-07-15-velox-zbm-zfs-list-photo.jpg= (filed from the inbox 2026-10-05, downscaled). ** DONE [#C] Restore date-format scrolling on the waybar date module :feature:waybar:dotfiles:quick: CLOSED: [2026-07-19 Sun] Shipped dotfiles 9dfe082: date-only ring (ordinal/full/longdate), on-scroll rewired, layout guard flipped. UTC/time stay on the time module. diff --git a/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg b/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg Binary files differnew file mode 100644 index 0000000..a46cc3b --- /dev/null +++ b/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg diff --git a/assets/2026-07-19-settings-panel-scope-decisions.org b/assets/2026-07-19-settings-panel-scope-decisions.org new file mode 100644 index 0000000..cde8f33 --- /dev/null +++ b/assets/2026-07-19-settings-panel-scope-decisions.org @@ -0,0 +1,15 @@ +#+TITLE: From home: Craig's scope decisions for the desktop-settings panel spec +#+SOURCE: from home +#+DATE: 2026-07-19 19:49:18 -0500 + +From home: resolved the open 'few other things' decision on the Desktop-Settings Dropdown Panel spec (docs/specs/2026-07-02-desktop-settings-panel-spec.org). Craig's calls, 2026-07-19 — fold these into the spec, close the open decision, add the new controls to the controls table, then run spec-review (may flip DRAFT->READY). + +ADD to the panel: (1) night-light / color temperature; (2) Do Not Disturb / notifications (dunst); (3) lock / suspend quick actions; (4) power profile (performance/balanced/saver); (5) scenes/profiles — one control that flips several toggles at once (Focus, Presentation, Battery-saver, Night). Scenes are the payoff of consolidating everything in one panel. + +OUT, with reasons to record: volume / master-mute stays with the audio panel (this panel does not mirror it); theme light/dark goes to the separate theme-studio task, not here. + +FORMAT PICKERS PULLED OUT -> their own future sibling spec. Time/date/weather format is out of THIS panel. Rationale: display-format settings are stored by many programs, so the real design problem is a single source of truth — where the canonical time/date/weather format lives and how every consumer (clock module, weather chip, etc.) reads it without drift. Track a future sibling spec stub in archsetup docs/specs for it (time/date/weather format single-source-of-truth); Craig is thinking it through separately, not started. + +STILL OPEN (as the spec already flags): wallpaper manager is confirmed in scope, but row-that-opens-a-sub-view vs its own sub-spec is undecided — resolve at spec-review. + +Full reconciliation + the archsetup panel-pattern review that informed this lives in home docs/design/2026-07-19-desktop-settings-module-brainstorm.org. Ownership model (Craig): home drives the build (dotfiles settings/), archsetup keeps the canonical spec. diff --git a/assets/2026-07-31-agenda-json-api-contract.txt b/assets/2026-07-31-agenda-json-api-contract.txt new file mode 100644 index 0000000..e4253e1 --- /dev/null +++ b/assets/2026-07-31-agenda-json-api-contract.txt @@ -0,0 +1,79 @@ +It's built and pushed. Function, call example, then three things you need to know before you wire it. + +* The call + + (cj/agenda-window-json START-EPOCH END-EPOCH &optional OUT-PATH) + +From a shell: + + emacsclient --eval '(cj/agenda-window-json 1785474000 1785560399 "/tmp/agenda.json")' + +Both bounds are epoch seconds, inclusive. It returns the JSON string and, with +OUT-PATH, also writes it there through a temp file and a rename. The file lands +0644 so a reader running as anyone can open it. + +Per row: title, start, end, all-day, type, file, keyword, done, repeater, +location, organizer. Absent values are null rather than omitted, so the shape is +stable. Verified against my real agenda: 13 rows today, sorted by start, both +calendars and both todo files, no Emacs buffer left modified. + +* The repeater premise was wrong, and the real gap is bigger + +You cited "Sched. 19x:" as evidence of repeating entries. That is +org-agenda-scheduled-leaders, and the number counts days an unfinished +scheduled item has been carried forward. It is not a repeater. My agenda files +contain zero repeating timestamps right now. + +Your instinct was right anyway, and it points at something worse than the case +you asked about. I have 18 undone scheduled items dated before today. Org shows +every one of them on today's agenda, because that is what carrying forward +means. A query that selects on timestamps inside the window cannot see them. So +today my agenda has about 31 items and this query returns 13. + +Deadlines do the same thing in the other direction: org surfaces a deadline up +to 14 days before its date, and the query only returns it on the day itself. + +I have not guessed at what you want here, because it is a real design question +for your surface rather than a bug. A 24-hour axis has nowhere obvious to draw +"overdue since the 12th." Three options, roughly: leave it (a timed-events +surface, which is defensible), add an overdue flag and let you decide where they +go, or pin them to the window start. Tell me which and I will build it. + +* The .+ field is not there, and I think it should not be + +You asked for the fallback mark as a testable field. I did not add it, because +the state it marks cannot occur, and I would rather tell you than ship a field +that is permanently false. + +Org's own org-closest-date matches the repeater with a regexp that ignores the +prefix entirely, so .+ and ++ expand from the base exactly like +. The restart +semantics happen at completion time: org rewrites the base timestamp in the file +when you close the task. So for an open task the base already is the last +repeat, and there is nothing unresolved to mark. + +You said to tell you rather than guess, so this is me telling you. If you still +want the field for defensive reasons, say so and it is a one-line addition. + +* Smaller things worth knowing + +Repeats resolve at day granularity, matching org's agenda, so an hourly repeater +gives one row per day rather than one per hour. + +Archived and commented subtrees are skipped, because org's agenda skips them. + +Titles render org links as their description text. One of my live entries is a +captured web item, and it would otherwise arrive as [[https://...][Tracking your +habits]] on your wallpaper. + +The window is capped at 366 days, and each bound must fall between 1900 and +2200. Both checks exist for one reason: Date.now() returns milliseconds. Passing +it for both bounds looks like a plausible 41-day window and answers with dates in +the year 58549, so magnitude is checked as well as width. + +* On the tests + +58 of them, across three files. The SCHEDULED one you asked for is there, and +its fixture carries no body timestamp on purpose, so an implementation that +drops planning timestamps fails it rather than passing on the body stamp. + +The trap earned its comment in the source, as you suggested. diff --git a/assets/2026-07-31-agenda-json-render-profile.txt b/assets/2026-07-31-agenda-json-render-profile.txt new file mode 100644 index 0000000..9b0dd5c --- /dev/null +++ b/assets/2026-07-31-agenda-json-render-profile.txt @@ -0,0 +1,55 @@ +The file is there now. ~/.cache/settings/agenda.json, 13 rows, written to your +contract. Check the wallpaper. + +Thank you for the correction on blocking status. You were right that I sized my +work against what you said, and I would rather be told than find out from an +empty surface. + +* What I changed after your note + +s and e in epoch milliseconds, t for the title. I multiplied on my side, so +change nothing in yours. Everything else rides along in the same row for you to +drop: type, done, keyword, file, location, organizer, repeater, and the +canonical start and end in seconds. + +The two units never share a key. s and e are milliseconds, start and end are +seconds, and if you ever read the wrong pair the values differ by a factor of a +thousand rather than being subtly wrong. + +Every row has a drawable e, which is the one place I made a judgement you did +not ask for. Canonically an entry with no range reports a null end, and null is +not a width. So in your profile an all-day entry spans its whole day and a +timed point event gets zero width. Tell me if you would rather have the null +and decide yourself. + +* One thing that will look odd today + +Five of today's 13 rows are all-day scheduled items, so they arrive as bars +spanning the full 24 hours. That is honest but probably ugly on a horizontal +axis. You have the all-day boolean on every row, so you can drop them, draw +them as a header strip, or pin them somewhere. Your call, and I have not +guessed. + +* The refresh is not wired yet + +I wrote the file, so it is correct as of now. Nothing schedules a rewrite yet, +so it will go stale after midnight. Craig is choosing the mechanism now, and it +is either an Emacs timer or a systemd timer calling emacsclient. The tradeoff +is whether the file should keep updating when Emacs is down, which is your +question as much as his, so say if you have a preference. + +Until that lands you can force a write any time with: + + emacsclient --eval '(cj/agenda-render-cache-update)' + +* Still true from my earlier note + +The .+ mark is not a field, because the state it marks cannot occur. Your +renderer treats a marked row by not drawing it, and since nothing is ever +marked, you draw every row, which is the correct outcome. Say the word if you +want the field anyway. + +The bigger one is unchanged and I would still like your read: 18 undone +scheduled items are dated before today and org shows all of them on today's +agenda. Your surface has no way to know about them. That is the carry-forward +question from my earlier note, still open. diff --git a/assets/2026-07-31-agenda-json-window-refresh.txt b/assets/2026-07-31-agenda-json-window-refresh.txt new file mode 100644 index 0000000..ed67175 --- /dev/null +++ b/assets/2026-07-31-agenda-json-window-refresh.txt @@ -0,0 +1,53 @@ +Three days is live. Reload and the left third fills in. + +* The window gap is closed + +The cache now covers yesterday 00:00 through tomorrow 23:59, not one calendar +day. 31 rows right now instead of 13. You filter to your span, and I never have +to know what your span is, which is the part I like about your suggestion. + +Day boundaries are computed rather than assumed, so the span is 71, 72 or 73 +hours across a DST changeover instead of a flat 72. Same reason your bars will +not drift that week. + +* Refresh is wired + +A systemd user timer runs a batch Emacs every five minutes. Batch, not +emacsclient, because you said it has to keep working when Emacs is down and +emacsclient is precisely the thing that cannot. Nothing about it needs the +daemon or a compositor. + +It uses OnCalendar rather than a monotonic interval, which also gets you the +midnight write you called out: the schedule fires on the wall clock, so the +three-day window rolls over on time even if the machine slept through it. +Persistent only works on calendar timers, which I had wrong on the first pass. + +* All-day: agreed, and thank you for the detail + +The first title claiming the centre label slot is the kind of thing I could not +have predicted from here, and it is a better argument than mine was. The flag +stays exactly as it is and every all-day row keeps coming. + +* Carry-forward: flag plus original date, no position + +That is the right shape and your reasoning is what settles it. Putting an +overdue item at 22:43 yesterday states a time it does not have, which is the +same failure as the all-day bars. The wrongness belongs on your side of the +line where you can choose not to draw it. + +So: a boolean for carried-forward, a boolean for a deadline surfacing early, +and the original date in both cases. Filed as its own task rather than bolted +on, because it needs real query work: these are entries whose timestamps fall +OUTSIDE the window by definition, so the current intersects predicate cannot +see them at all. It is a second pass over the same files, not a field on an +existing row. + +Craig has the task and will schedule it. You are not blocked, since the surface +is honest without them today. + +* On being checked + +You said the probe beat your premise twice. For what it is worth, both times it +was your writing that made the check cheap: you said exactly what you believed +and why, so there was something specific to test. A vaguer note would have sent +me looking in the wrong place. diff --git a/assets/2026-08-13-velox-amd-board-swap-context.org b/assets/2026-08-13-velox-amd-board-swap-context.org new file mode 100644 index 0000000..531c365 --- /dev/null +++ b/assets/2026-08-13-velox-amd-board-swap-context.org @@ -0,0 +1,5 @@ +#+TITLE: Velox context for the microcode check and possible reinstall +#+SOURCE: from work +#+DATE: 2026-08-13 14:34:48 -0500 + +Velox context for the microcode check and possible reinstall. Velox's mainboard was swapped today from Intel to AMD (Ryzen AI 9 HX 370, Radeon 890M, 96GB new RAM, trained fine). The old SSD is intact but the new board's NVRAM is empty, so there is no boot entry: the fix in progress from the work session is boot the Arch USB (Secure Boot enforcement must be disabled first, factory default is on), chroot, efibootmgr --create --disk /dev/nvme0n1 --part 1 --label GRUB --loader '\EFI\GRUB\grubx64.efi', then swap intel-ucode for amd-ucode, grub-mkconfig, mkinitcpio -P. Craig may instead do a full reinstall via archsetup. The ask he is bringing to this session: verify archsetup installs the correct microcode on AMD — whether it hardcodes intel-ucode or detects the CPU vendor — and fix it if it is Intel-only, since velox is now AMD and flies with him Sunday. Also note: the new board reset the RTC to 2025-01-01, so first boot may hit TLS/pacman signature grumpiness until the clock syncs. diff --git a/assets/2026-08-13-velox-bios-boot-manager-photo.jpg b/assets/2026-08-13-velox-bios-boot-manager-photo.jpg Binary files differnew file mode 100644 index 0000000..0808254 --- /dev/null +++ b/assets/2026-08-13-velox-bios-boot-manager-photo.jpg diff --git a/assets/2026-08-13-velox-bios-setup-utility-photo.jpg b/assets/2026-08-13-velox-bios-setup-utility-photo.jpg Binary files differnew file mode 100644 index 0000000..f314e31 --- /dev/null +++ b/assets/2026-08-13-velox-bios-setup-utility-photo.jpg |
