dotemacs/tests/test-ai-vterm--f9-in-vterm.el, branch load-graph-classify-start

feat(ai-vterm): add graceful agent close on M-f9 / C-S-f9

2026-05-22T00:38:05+00:00

cj/ai-vterm-close tears an agent down cleanly: it kills the agent's tmux session (stopping the process), removes the vterm window when it isn't the only one in the frame, then kills the buffer. It targets the current agent buffer, the sole live agent, or prompts among several, and confirms before killing since that interrupts work in progress. I also folded the whole F9 family onto ai-vterm. M-f9 used to run cj/toggle-gptel, but gptel is broken right now (the local fork doesn't load, so gptel-make-anthropic is void), and grouping every ai-vterm command under F9 reads better anyway. M-f9 is the primary close binding. C-S-f9 is a second binding that the Wayland/PGTK layer may swallow on some machines. I covered it with 7 tests over the tmux-kill helper, the per-buffer teardown, and target selection, mocking process-file and the prompt at the boundary.

fix(ai-vterm): autoload cj/toggle-gptel to silence cross-module warning

2026-05-15T07:21:57+00:00

make compile warned that cj/toggle-gptel is not known to be defined when ai-vterm.el is byte-compiled. The M-F9 binding still worked during normal startup because init.el loads ai-config.el after ai-vterm.el, but the dependency was implicit -- byte-compile saw the function symbol unresolved, and loading ai-vterm.el in isolation left M-F9 bound to an undefined function. Declare cj/toggle-gptel as an interactive autoload pointing at ai-config. This silences the warning, keeps ai-vterm.el free of a load-time (require 'ai-config), and makes the load-order contract explicit: the binding works as long as ai-config eventually loads. Test asserts that requiring ai-vterm in isolation leaves cj/toggle-gptel fboundp as an autoload sigil (not a real function). A regression that adds (require 'ai-config) at the top of ai-vterm.el would flip this, and a regression that drops the autoload form would leave fboundp nil.

refactor(ai-vterm): retire M-F9 buffer picker; bind to cj/toggle-gptel

2026-05-15T04:59:34+00:00

M-F9 used to invoke `cj/ai-vterm-pick-buffer' (a buffer picker narrowed to alive AI-agent buffers). In practice the F9 plain-key toggle + C-F9 project picker covered the common cases, and the buffer picker rarely earned its keystroke. Rebind M-F9 to `cj/toggle-gptel' so the F9 family covers the two main in-Emacs AI surfaces at one keystroke each: ai-vterm toggle (unchanged) C- ai-vterm picker (unchanged) M- gptel *AI-Assistant* (NEW) Removed entirely: - `cj/ai-vterm-pick-buffer' (the command itself). - `cj/--ai-vterm-pick-buffer-candidates' (its helper). - `tests/test-ai-vterm--pick-buffer-candidates.el' (deleted). Updated: - `tests/test-ai-vterm--f9-in-vterm.el' binding assertions (vterm-mode-map and global) flipped to `cj/toggle-gptel'. - Module commentary + `cj/ai-vterm' docstring describe the new M-F9 behavior. - `cj/toggle-gptel' lives in `modules/ai-config.el'; the binding stays in `ai-vterm.el' next to the rest of the F9 family so the dispatch shape is visible in one place.

fix(ai-vterm): make F9 toggle the agent from inside an agent buffer

2026-05-12T17:53:11+00:00

vterm binds ``..`` to `vterm--self-insert`, so a plain `` typed while point is in an agent buffer goes to the terminal program instead of the global toggle. That's invisible most of the time — you press F9 from another window — but it bites when the agent buffer is the only window in the frame, because there's nowhere else to press it from. I re-bound the F9 family in `vterm-mode-map` (via `with-eval-after-load 'vterm`) so that ``, `C-`, and `M-` reach `cj/ai-vterm`, `cj/ai-vterm-pick-project`, and `cj/ai-vterm-pick-buffer` from there too. The C-/M- variants aren't actually in vterm's intercept set, but binding them keeps things uniform. New `tests/test-ai-vterm--f9-in-vterm.el`: 4 ERT tests over the `vterm-mode-map` and global bindings. F12's `cj/vterm-toggle` has the same shape of bug and isn't touched here.