| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
The prior fix listed drill files with a raw directory-files call, bypassing cj/--drill-files-or-error, the shared validated entry point the other drill commands use. That skipped the missing/unreadable-dir user-error, fell through silently on an empty dir, and included leading-dot .org files the module otherwise excludes. Route through cj/--drill-files-or-error + expand-file-name, keeping the let binding so the session-wide org-refile-targets still survives. The test is rewritten into three: validated-helper targets, no global clobber, and a user-error on a missing drill dir.
|
| |
|
|
| |
dashboard-config used setq on recentf-exclude, discarding the five exclusions system-defaults adds earlier in init order (bookmarks, elpa, recentf, ElfeedDB, airootfs). Extract the EMMS exclusion into cj/--dashboard-exclude-emms-from-recentf (the :config side-effect was not reachable for a test) and use add-to-list so prior entries survive. Two ERT tests cover preservation and the added pattern.
|
| |
|
|
| |
cj/drill-refile used setq, permanently replacing the session-wide org-refile-targets so every refile anywhere offered only drill targets until restart; and its (drill-dir :maxlevel . 1) entry named a bound variable, which org reads as a directory string rather than a file list, so the drill side yielded nothing. Let-bind org-refile-targets and supply (directory-files drill-dir t "\\.org$") as the file list. The stale test (which asserted the buggy drill-dir spec) is rewritten into two: file-list targets and no global clobber.
|
| |
|
|
| |
Meta+Shift+<letter> emits the uppercase event (M-E/M-R/M-B), so the M-S-e/M-S-r/M-S-b :bind specs on lowercase letters were never reached by the keychord and the three launchers were dead. Rebind them to M-E/M-R/M-B. Three ERT tests assert each chord resolves to eww, cj/elfeed-open, and calibredb respectively.
|
| |
|
|
| |
The "d" dailies head ran FILETAGS and TITLE together with no newline, so every C-c n d daily was malformed: Org never parsed #+TITLE and the FILETAGS value swallowed the rest of the line. Extracted the head into the cj/--org-roam-dailies-head defconst so it is unit-testable (the value was unreachable inside the use-package :custom form) and gave it real newlines. Two ERT tests assert the FILETAGS/TITLE line separation and the trailing newline.
|
| |
|
|
| |
(interactive "p") forces arg >= 1, so the old (if arg (nth arg ...) (car ...)) always took the nth branch and plain M-S-z re-opened the second-most-recently-killed file. Index with (nth (1- arg) ...) so a numeric prefix is 1-based and no prefix re-opens the most recent. The two undo-kill tests now exercise the real no-prefix path (arg=1 reopens the first) and a 1-based numeric prefix; both failed against the bug and pass after. Filed a follow-up for a separate delq-vs-delete skip-visited defect found in the same function.
|
| |
|
|
| |
Filed each task's pending manual check under the Manual testing and validation parent (relocated Signel's two existing checks, created three new ones), then closed the implementation tasks: Calibre bookmark naming, Calibre keybinding menu, Signel notify-only-for-unviewed-conversation, and project-aware capture.
|
| |
|
|
| |
Document the six allowed task tags (bug, feature, refactor, test, quick, solo) in the priority scheme and strip every other tag from Open Work, normalizing tests to test. Re-audit solo and quick against the rubric. Close three stale parents whose children all landed (org cache lifecycle, shell-command audit, UI/navigation hardening) and drop a duplicate ghostel Phase 2 task already logged as done.
|
| | |
|
| | |
|
| |
|
|
| |
Full audit of all 121 modules plus init/early-init, four holistic passes (startup/perf, stability, UX consistency, packages), and spin-off reviews of pearl, chime, and emacs-wttrin. ~235 findings: 40 high-impact bugs as standalone tasks, the rest under the audit parent's group children, with a synthesis child carrying the attack order. Also files the messenger-unification, Google Voice, and Google Contacts brainstorm tasks.
|
| |
|
|
| |
Five manual checks verified, closing the contrast-cell and preview-bg bugs. An audit of the bespoke previews found three face mislinks (org headline-todo, erc input/default swap, flycheck delimiter swap) — filed with picker-visibility and Rust+Zig sample tasks. WIP theme picks up the revised steel selections.
|
| | |
|
| | |
|
| |
|
|
| |
notify slice
|
| |
|
|
| |
Adds the scheduled palette-columns spec review, the agent-KB memory-sweep task from the rulesets rollout, and a preview window-split issue; the closed bevel and color-harmony tasks move to Resolved.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
org-lint's misplaced-heading checker flags any mid-line "** " in a paragraph. The quoted "** TODO" examples in two manual-test Expected lines tripped it.
|
| | |
|
| |
|
|
| |
The two color-sorting reviews resolved the warm-color grouping problem; LCCL is implemented (04b82bbe). The only remaining piece, a per-hex family-hint override for the irreducible ramp-collision case, is filed as its own task.
|
| | |
|
| |
|
|
|
|
|
|
| |
Export stays a flat palette and import needs no reconstruction, because families are derived from the hex every render rather than stored. A #roundtriptest gate confirms export to import to export is byte-identical, and that the exported palette is still a flat [hex, name] list. Package seeding is unaffected since it reads the same flat palette.
The spec's planned ramp-step warning exemption is dropped after analysis: a generated ramp's steps are a stepL apart, well above the too-similar ΔE threshold, so they never trigger the warning, and exempting same-family pairs would hide genuine near-duplicates that should be flagged (the case #deltatest checks). So the warning stays on the full palette.
README documents color families: the hue grouping and its limitation, the ground strip, the per-column count control and regenerate, removed-step references reading "(gone)", and the removal of the standalone ramp panel. Phase 6, the last phase; the color-families v1 build is code-complete.
|
| |
|
|
|
|
|
|
|
|
| |
neutral cut
Replace gap-based hue clustering and the flat neutral threshold. Chromatic colors now bucket by nearest perceptual hue anchor (red, orange, yellow, green, teal, blue, purple, pink), so adjacent categories stay separate by construction and there's no single-linkage chaining merging them through intermediate tones. The neutral cut is lightness-scaled rather than flat: a color reads as neutral below a chroma that's highest in the mid-tones and tapers toward the light end, so a faint mid gray goes neutral while an equally-faint pale tint keeps its hue.
This fixes the two concrete problems: the grays and steels consolidate into one neutral column, and pale tints (light blues) stay with their hue instead of falling into the grays. What it doesn't fix is hue-adjacent warm colors: this palette's olive-greens sit on top of the golds in OKLCH hue, so they still group together, and a ramp that drifts in hue can split across an anchor boundary. That's a real property of the colors, not a bug, and it's filed for research (a writeup of the problem and the four approaches tried lives outside the repo; the task points to it).
20 family node tests including the yellow/green split and the no-chaining case; suite green.
|
| |
|
|
| |
Craig confirmed the spec Ready. The six phases become tracked tasks under the color-families parent — family model and sort cores, strip rendering, the count control, the ground strip plus ramp-panel retirement, and the warnings/seeding/export/README close-out — all :solo:. Three manual aesthetic checks (hue grouping matches the eye, regenerate-replace reads as deliberate, removed-step references read as "(gone)") go under the Manual testing parent.
|
| |
|
|
|
|
|
|
| |
Resolved both open decisions per Craig: theme.json stays flat, and the standalone ramp panel goes away in favor of the per-strip control. The bigger change is the grouping mechanism: families are now derived from OKLCH hue off the hex, never from a name convention, so renaming a color to anything never moves it between strips.
That pivot designs out the Codex review's two hardest blockers. There's no step-name grammar and no import inference, because grouping isn't name-based. And the palette stays a flat, individually-editable list rather than transferring ownership to family objects, so per-chip rename/remove/edit keep working and there's no ownership contract to invent. Families are a display view over the existing palette.
The rest of the review is folded as written, adapted to the flat model: the ground strip is synthesized from the bg/fg assignments (pinned, editable, de-duped by hex), removed-step references degrade to a visible "(gone)" rather than a silent jump, n=0 is handled without ramp(), and the neutral (0.02) and hue-gap (25) thresholds and sort tie-breakers are pinned. Review file consumed and deleted; dispositions and a responder entry are in the spec.
|
| |
|
|
|
|
| |
The palette panel becomes color families instead of a flat row of chips: a base color plus its tonal ramp, shown as a dark-to-light strip with a per-family symmetric step count (N gives base ±N). Families are live, so changing the count or the base regenerates the strip; regeneration is authoritative. fg and bg share a fixed ground strip, other standalone colors are singletons, and strips sort by hue across the panel with steps sorted by lightness within.
The spec keeps theme.json a flat palette (families derived from the ramp naming on import) and reuses the shipped ramp() and assignment re-point. Two decisions are left open for Craig: flat-vs-structured persistence, and whether the per-family count control should replace the standalone ramp panel. Six phases, each leaving the tree green; the v1 build it extends is cross-linked from the task.
|
| |
|
|
| |
All five build phases plus the README close-out landed; the parent stays open pending the manual aesthetic and real-Emacs-fidelity sign-off.
|
| | |
|
| |
|
|
|
|
| |
The palette-ramps spec is Ready, so its six phases become tracked tasks under a v1 build parent: ramp core, ramp UI, foreground-set/floor/lMax core, worst-case readout, safe-lightness picker, and a README plus test-surface close-out. All six are :solo: — each verifies through node tests or a headless hash-gate plus a screenshot read.
The aesthetic and real-Emacs-fidelity checks that need Craig's eye go under the existing Manual testing parent: does a generated ramp harmonize, does the safe-lightness guidance read clearly, and does a tint the tool calls safe actually keep every token readable behind real syntax.
|
| |
|
|
|
|
|
|
|
|
| |
Resolved both open decisions. The contrast target is WCAG AA by default, with AAA selectable and APCA shown as a diagnostic only. The v1 foreground set is the distinct syntax-assignment hexes plus the default foreground, with locked background-only roles excluded.
Pinned what the review flagged as underspecified: a closed five-face covered set (region, hl-line, highlight, lazy-highlight, isearch), ramp defaults and palette-insertion rules (n/stepL/chromaEase, naming, collisions, clamp display), and explicit-state structured-error contracts for ramp, fgSetFor, floor, and lMax. Package and non-overlay UI cells stay single-pair in v1.
Closed the v1 face set rather than keeping the review's open-ended "any face the buffer renders text over" clause, since an open set reintroduces the gap the foreground-set decision exists to close. Kept throwing for genuine programmer error while returning structured results for bad user input, matching colormath.js.
The spec is implementation-ready. The six implementation tasks get created once Craig confirms the go. Review file consumed and deleted.
|
| |
|
|
| |
Design doc (spec-create workflow) for two coupled v1 features: generating a harmonized tonal ramp from a base color, and a worst-case-contrast readout that caps a background tint at the lightness where every foreground on it stays readable. Cross-linked from the color-harmony task; harmonic fill deferred to vNext.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
consistency-check tasks
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
