From b72e794be60c5d4e94c61e5af8c08245773e3393 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 31 May 2026 16:20:34 -0500 Subject: feat(ai-vterm): gate the F9 launcher to GUI frames AI-vterm launches a graphical vterm side window, so F9 / C-F9 / M-F9 now decline with a message in a terminal frame instead of opening a vterm. The guard checks the current frame at command time rather than at load. That matters under the daemon, which serves GUI and terminal frames both with display-graphic-p nil at load, so a load-time gate would have disabled the launcher in its GUI frames too. Routed the three window-behavior tests through a GUI-frame stub, since a batch run is itself a terminal frame. --- todo.org | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'todo.org') diff --git a/todo.org b/todo.org index 6fa2161e..0b9f8c2e 100644 --- a/todo.org +++ b/todo.org @@ -153,6 +153,14 @@ What we're verifying: emoji glyphs + fonts apply in a GUI frame even when the fi - in the GUI frame, open a buffer with an emoji and check it renders, and M-S-f / fonts look right Expected: emoji renders and fonts are applied in the GUI frame. +*** AI-vterm declines in a terminal frame, still launches in a GUI frame +What we're verifying: the per-frame guard makes the F9 family decline — message only, no vterm — in a terminal frame, while a GUI frame still launches the agent. +- emacsclient -t (TTY frame, off the running daemon) +- in the TTY frame, press F9 (also try C-F9 and M-F9) +- emacsclient -c (then a GUI frame) +- in the GUI frame, press F9 and pick a project +Expected: in the TTY frame the echo area shows "AI-vterm is GUI-only; not available in a terminal frame" and no vterm opens; in the GUI frame the project picker opens and the agent launches as before. + ** DOING [#B] Consolidate to EAT as the single terminal :terminal:eval: :PROPERTIES: :LAST_REVIEWED: 2026-05-28 -- cgit v1.2.3