| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Gptel Work project asked for a survey of published gptel tools
with adopt / skip / defer decisions per candidate. I can't do a
live community-tool survey from this session, so the doc covers
the candidates the task body called out plus a few obvious
adjacents.
Decisions:
- ADOPT (7): `search_in_files`, `git_status` / `git_log` /
`git_diff` (three tools), `web_fetch`, `search_emacs_help`,
`find_file_by_name`, `take_screenshot`. Each gets a sketch in
the doc -- args, validation posture, implementation outline.
- DEFER (2): `run_shell_command` (huge surface, click-fatigue
risk; the ADOPT-bucket tools cover most legit use cases),
`org_capture` (needs UX design for template pre-fill and the
round-trip).
- SKIP (1): `eval_elisp` (code execution from a model is too
dangerous even with confirm-each-call).
The doc also lists three follow-ups: the live community survey
that this session couldn't do, per-tool implementation sub-tasks
to be filed under the next iteration of Gptel Work, and a
sandboxing-convention decision for `web_fetch` (allowlist of
outbound URLs vs description-only warning).
Three open questions at the bottom of the doc for review:
build-all-at-once vs paired stages, `fd` as a hard dep vs `find`
fallback, Hyprland-only screenshot vs Wayland-generic via a
portal.
Closes the Gptel Work PROJECT for this iteration -- all 9 in-scope
sub-tasks landed this session.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The spec lays out the EMMS-removal design: package-owned track and
playlist structs, a narrow backend protocol with mpv as the v1 backend,
state-change hooks replacing EMMS player hooks, an overlay-based
selected-track marker, a fake-backend test architecture, a quantified
performance budget, a 22-step parity walk, and the migration plan.
The review tracks implementation readiness: which migration-plan step
is safe to start, which decisions still block the rest, and the exact
spec edits required.
Two decisions landed this session and are now baked into the spec:
- Platform support: Linux and macOS get full features; Windows runs in
degraded mode (play/stop/next/previous only) because Emacs cannot
natively connect to mpv's Windows named-pipe IPC. Anyone who wants
full Windows parity can wire mpvc.exe shellout or a w32-* named-pipe
client as a follow-up.
- File-extension scope: cj/music-file-extensions stays as-is. webm and
ape files in ~/music are intentionally skipped.
Socket path now references temporary-file-directory instead of a
hardcoded /tmp/ prefix so the spec stays consistent with the Windows
section.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replaces the .ai/ draft (2025-11-14) with a corrected and tightened
version under docs/design/. The earlier draft had stale line numbers
pointing at a modeline-config.el layout that no longer exists,
conflated Option 3's risky-local-variable requirement with Option 4's
inline (:eval ...) approach, and missed the active-window gating
convention used by the rest of the modeline.
The new spec uses concrete line refs against current code, calls out
flycheck-mode-line-color (which the old draft missed), recommends
calling flycheck-mode-line-status-text directly instead of returning
the nested (:eval ...) cons, and gates the segment to active window
for consistency with cj/modeline-vc-branch and cj/modeline-misc-info.
todo.org task points at the new path and drops the broken
docs/flycheck-modeline-customization-spec.org link.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replaces a thin third-party config snippet (one use-package corfu + one
use-package cape, with no migration steps and no prescient piece) with
a full spec covering the current company stack: corfu, cape,
corfu-popupinfo, kind-icon, corfu-prescient.
Maps every current company setting to its corfu equivalent
(idle-delay, prefix-length, tooltip-limit, wrap, require-match,
global-mode exclusions, doc popups, icon kinds, prescient sort).
Walks the per-module fixups -- selection-framework, mail-config,
ledger-config, latex-config, eshell-config, and the three prog-*
mode hooks. Adds a test plan and risks section.
todo.org points at the new doc; the broken :COMPLETE_CONFIG:
property (which referenced the wrong line range in someday-maybe)
is gone.
|
| |
|
|
|
|
|
|
| |
Per Phase 5 step 1 of utility-consolidation. Specifies the cache API to extract from org-agenda-config and org-refile-config (both have parallel TTL+building-guard implementations today). Documents the API: `cj/cache-make', `cj/cache-valid-p', `cj/cache-value-or-rebuild', `cj/cache-building-p', `cj/cache-invalidate'.
Out-of-scope: modeline VC cache (buffer-local + key-based, not TTL). Per the spec, that's a future round.
Documents the migration order (agenda first, refile second), test plan for the helper, and risk notes (cache-hit logging preservation, building-flag leak guard, async-timer interaction).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Phase 1 of utility-consolidation per docs/design/utility-consolidation.org. The inventory walks the spec's 30-entry Candidate Extraction Table and, for each helper, records: visibility, dependencies, side effects, callers in modules and tests, test file location, extraction priority, and a Migrate / Leave / Defer decision with rationale.
Decisions: 11 Migrate, 3 Leave, 13 Defer. The Migrate items are grouped by phase in the spec's recommended order: Phase 2 (foundation helpers -- executable lookup, shell quoting, process runner, file-from-context), Phase 3 (Org-safe text sanitizers), Phase 4 (external-open consolidation). The Defer items mostly need a second production caller before promotion is justified.
Discoveries worth recording: `cj/log-silently' already has 10 production callers (more than the spec's table suggested), and `cj/--file-manager-program-for' shipped today in dirvish-config.el is the new form of OS-dispatch consolidation -- Phase 4's `cj/external-open-command' should fold it in rather than re-deriving.
No code behavior changes -- this is the spec's stated Phase 1 exit criterion.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Two post-ship issues blocked practical use of the new launcher.
The display rule used `display-buffer-in-side-window` with `(dedicated . t)`. Side-window dedication caused `set-window-buffer` to error during `buffer-move` (C-M-arrows), which left a half-finished swap with both sides showing the claude buffer. Then `switch-to-buffer` on a non-claude buffer in that dedicated window split instead of replacing.
I rewrote the rule as `display-buffer-reuse-window -> display-buffer-use-some-window -> display-buffer-in-direction (right)`. The resulting window is ordinary, not dedicated, so swap and replace work normally. I also narrowed `vterm-toggle`'s broad lambda (which matches any vterm-mode buffer) to exclude `claude [` buffers. Otherwise vterm-toggle's `:defer` made it install last and capture our buffers first with its own bottom-split + dedicated treatment.
The tmux side: vterm's auto-launch hook ran a bare `tmux\n`, so each session got an auto-named one. After an Emacs crash the tmux session would survive but I couldn't find it. A second F9 just spawned another. The launcher now sends `tmux new-session -A -s <basename> -c <dir> '<claude>; exec bash'`. The `-A` reattaches to a same-named session if it already exists. The `exec bash` keeps the tmux window alive if claude itself exits. A `cj/--ai-vterm-suppress-tmux` flag tells the existing vterm hook to skip its bare tmux step so the named launch runs instead.
11 new tests across 2 files cover the session-name and launch-command helpers. I updated tests for show-or-create and the display rule. All 34 ai-vterm tests are green.
|
| |
|
|
|
|
|
|
| |
The new module picks a Claude-template project from a filtered completing-read list. It scans the same roots the `ai` shell launcher uses, then opens or reuses a vterm buffer named `claude [<repo>]` on the right. F9 launches it. The prior `cj/toggle-gptel` binding moves from F9 to C-F9 so both AI tools share the same physical key.
The display rule chains reuse-window -> use-some-window -> in-direction (right). The resulting window isn't dedicated. That matters because side-window dedication was breaking `buffer-move` (C-M-arrows) and `switch-to-buffer` replacement on the claude buffer. I also narrowed `vterm-toggle`'s display rule to skip `claude [` buffers. Otherwise it claimed them first with its bottom-split + dedicated treatment.
I added 23 tests across 5 files: the buffer-name transform, candidate walker, show-or-create dispatch, picker, and display rule. Design lives at docs/design/ai-vterm.org.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I added two sibling design specs in `docs/design/`:
`init-load-graph.org` covers untangling `init.el` from its current "everything eager in a fixed order" shape. It defines a layered architecture (early-init / foundation / core UX / domain workflow / optional), a module category table for every required file, a per-file commentary header standard with seven required lines, a six-phase migration plan with exit criteria, and a testing strategy split into automated batch checks, manual smoke checks, and startup performance baselines via `benchmark-init`.
`utility-consolidation.org` is the sibling project. It covers extracting reusable helpers from feature modules into `system-lib.el` and a small set of topic libraries (`cj-process.el`, `cj-org-text.el`, `cj-cache.el`). It includes a candidate decision criteria section, a library file header standard with worked example, a candidate extraction table with priorities and proposed names, nine helper groups with API plus behavior contracts, naming rules, migration phases, test relocation policy, and a recommended first-three-commits sequence.
Both specs are draft. No code change in this commit. The two projects are intentionally separated because the load-graph project asks "when does this load?" and the consolidation project asks "who owns this helper?". Those are different questions with different rollback shapes.
Implementation tracking lives in `todo.org`.
|
| |
|
|
| |
Captures the v1 design for the gloss Emacs package: layered five-module split, Wiktionary REST as the online source, side-buffer picker for ambiguous terms, libxml HTML strip, mtime-based cache invalidation. The implementation is a separate repo, but the design work happened in this tree, so the doc lives alongside the other design archives here.
|
| |
|
|
|
|
|
|
|
|
| |
Captures the agreed v1 shape for a new =debug-profiling.el= module: targeted slow-command investigation, two features ("profile next command" and "time region or sexp"), each split into pure helper plus interactive wrapper. Migrates the existing =profiler-*= bindings and =cj/benchmark-this-method= out of =config-utilities.el=. Stays on the existing =C-c d= debug umbrella prefix.
Six approaches were considered: three conventional, plus three tail samples (macro-first, log-and-grep, treesit picker). Recommendation is the boring named-operation surface backed by a thin wrapper over the built-in =profiler.el= and =benchmark.el=. The other five options are recorded with reasons-rejected so a future reader can see what was weighed.
Design covers architecture, data flow, error handling, testing approach, and observability. Two open questions are parked: default REPS for =cj/time--expr=, and whether to capture =cpu+mem= or just =cpu=. Both are fine to defer until v1 has been used on the queued org-capture target-building investigation.
Implementation will run via =/start-work= against this design.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completes the coverage v1 pipeline by adding the Makefile target, the undercover driver script, the exclusion list, and the .gitignore entry. Uses simplecov JSON rather than LCOV as the collection format.
The LCOV vs simplecov choice: Undercover's :merge-report t option only supports simplecov. Since the pipeline runs tests per-file (matching test-unit's isolation pattern) and accumulates coverage across runs, merge-report is required. LCOV is better-supported by external coverage viewers, but for a primarily interactive workflow the on-disk format is an internal detail.
Other moves in this commit:
- Renamed cj/--coverage-parse-lcov to cj/--coverage-parse-simplecov and rewrote its tests for the JSON schema. Same signature, same semantics (file to set of covered lines), different parser.
- Renamed the backend protocol's :lcov-path key to :report-path, format-neutral and matching the renamed cj/--coverage-elisp-report-path function.
- The coverage target deletes modules/*.elc before running so undercover can instrument the .el sources. Without this, byte-compiled versions shadow the instrumentation and only a handful of pre-loaded modules end up with coverage data.
- Excluded tests/test-all-comp-errors.el from make coverage runs. That test byte-compiles every module, which fails under undercover's instrumentation. Excluded only from coverage. Normal make test still runs it.
- Updated docs/design/coverage.org to reflect the simplecov pivot with a historical note on why we moved off LCOV.
Verified end-to-end: make coverage produces .coverage/simplecov.json with 2717 of 4559 executable lines hit across 44 tracked modules.
|
|
|
Two new design docs for pending todo.org tickets.
docs/design/coverage.org describes diff-aware coverage reporting with pluggable backends. Primary use case is pre-commit feedback on in-flight changes. LCOV is the shared output format across languages.
docs/design/dev-setup-project.org describes an interactive helper that detects a project's shape and writes per-subdirectory .dir-locals.el files for the F4/F6/F7 dev block, with optional starter Makefile generation. Three-tier detection: existing Makefile, existing package.json or pyproject.toml scripts, or fall-back generation.
Both tickets in todo.org reference their design docs via org file: links.
|
