My Emacs configuration https://git.cjennings.net/dotemacs/atom?h=main 2026-05-03T22:58:42+00:00 2026-05-03T22:58:42+00:00 Craig Jennings c@cjennings.net 2026-05-03T22:58:42+00:00 urn:sha1:dbce94b38f3267e59b015880d34ff31104126e47 I had four call sites passing literal nil to `projectile-compile-project' / `projectile-run-project' / `projectile-test-project'. The literal nil ignored whatever prefix arg the user gave. So `C-u F4 → Compile' or `C-u F6 → All tests' didn't actually force projectile's re-prompt — the prefix arg got swallowed at our wrapper layer. Switched all four to `current-prefix-arg': - `cj/--f4-dispatch' — `compile-only' and `run-only' actions. - `cj/f4-compile-only' — the C-F4 fast path's compiled-project branch. - `cj/f6-test-runner' — the "All tests" menu entry. Use case: when projectile's cached cmd is wrong (typo, stale, or whatever), `C-u' on any of these forces projectile to re-prompt instead of replaying the bad cmd silently. The compile-and-run and clean-rebuild paths still pass nil to their chained projectile calls because those run inside an async `compilation-finish-functions' hook, where `current-prefix-arg' has already reverted to nil. Refining those would need to capture the prefix at entry and thread it through; left for later. TDD: 4 new tests (one per call site) bind `current-prefix-arg' to t and verify projectile receives t. Each test failed against the literal-nil version and passes against `current-prefix-arg'. 2026-05-03T21:13:21+00:00 Craig Jennings c@cjennings.net 2026-05-03T21:13:21+00:00 urn:sha1:2c94acd52cc92dc4ebefd999dbca771367cc3090 I added a new module `modules/dev-fkeys.el` that owns the dev F-key block. F4 prompts via `completing-read` with a candidate set filtered by project type (compiled / interpreted / unknown). C-F4 is the compile-only fast path. M-F4 is clean + rebuild. It runs a heuristic clean command derived from the project markers (go.mod, Cargo.toml, Eask, Makefile, CMakeLists.txt) and chains `projectile-compile-project` on success. S-F4 stays on `recompile` and now lives globally instead of duplicated across prog-general.el and prog-c.el. F6 is bound globally to `projectile-test-project` as a Phase 1 stopgap. Phase 2 replaces it with the polyglot test runner spec'd in todo.org. Project-type detection runs against the projectile root and falls back to `unknown` when no marker matches. Interpreted markers are checked first so a Python or Node project with a Makefile for tasks classifies as interpreted instead of compiled. Compile + Run sequencing uses a one-shot `compilation-finish-functions` hook that self-removes on first invocation and only fires the follow-up when the status string starts with `finished`. Cleanup in the same commit: - Dropped F4/F5/F6 from `prog-general.el`'s prog-mode-hook. They are now global. - Dropped F6→format bindings from prog-c.el / prog-python.el / prog-shell.el. C-; f was already bound in each, so this is pure removal. - Dropped the duplicate S-F4 from prog-c.el. The global binding covers it. - Updated the keybinding header in prog-general.el and the workflow comments in prog-c.el / prog-shell.el. - Wired `(require 'dev-fkeys)` in init.el alongside coverage-core. TDD: 73 tests across 11 files, one per helper. Production code is split into small testable internals (`cj/--detect-project-type`, `cj/--f4-candidates`, `cj/--f4-derive-clean-cmd`, `cj/--f4-make-once-hook`, `cj/--f4-dispatch`, `cj/--f4-compile-and-run-impl`, `cj/--f4-clean-rebuild-impl`, `cj/--f4-project-root`) plus three thin interactive wrappers. Smoke tests confirm bindings register on load. Known limitation: if another `compilation-finish-functions` hook fires between my add-hook and the compile finishing, the chain can fire on the wrong compile. The hook self-removes on first invocation regardless of which compile it sees. Documented in the impl docstring. Acceptable for v1. Phase 2 will replace F6 with the polyglot test runner (tree-sitter queries for Python/Go/TS, sexp scan for Elisp, buffer-local last-test memory).