dotemacs/tests/test-vterm-copy-mode-cursor.el, branch load-graph-classify-start

feat(vterm): unify the keys in vterm copy-mode and tmux history

2026-05-11T15:02:17+00:00

`vterm-copy-mode' and the `C-; x h' tmux-history buffer now share one key story. `M-w' copies the active region and stays put, so I can copy several things in a row. `C-g', `', or `q' leaves (resuming the live terminal, or closing the history buffer) without copying. `RET' is unbound (no special "copy and exit"). In copy-mode that meant removing vterm's default `RET' -> `vterm-copy-mode-done' binding. Before, `M-w' exited and copied as it went, which made grabbing more than one selection awkward. The history buffer's `cj/vterm-tmux-history-copy-and-quit' was the copy-and-exit one-shot. It's gone. `M-w' then `q' is the equivalent. I also moved `cj/vterm-tmux-history' from `C-; x C' to `C-; x h' (unshifted, and it frees `C') and refreshed the file's stale commentary header, which still referenced the old `C-; V' prefix and `'.

fix(vterm): use a block cursor in vterm-copy-mode

2026-05-10T17:23:14+00:00

The 3-pixel bar was visible but a block matches the rest of my Emacs cursor and lets the standard cursor color and `blink-cursor-mode' behavior carry through unchanged. Same enter/exit semantics: forced visible on entry, buffer-local override killed on exit so the live terminal goes back to the TUI's chosen state. Update the test expectations and rename the "prior-was-box" boundary test to "prior-was-hbar" so it still proves the override does something (the prior and the override would otherwise both be `box').

test(vterm): cover the copy-mode exit chain end-to-end

2026-05-10T17:19:17+00:00

The unit tests for the cursor-restoration hook only exercised the helper in isolation. The real integration -- toggling the minor mode and watching the hook fire as part of the chain -- wasn't covered. If `vterm-copy-mode-done' or `cj/vterm-copy-mode-cancel' broke their exit semantics (or our hook stopped firing on `vterm-copy-mode-hook'), the unit tests would still pass but the cursor would stay stuck on the bar in real use. Add five integration tests that toggle the actual minor mode through stubbed `vterm--enter-copy-mode' / `vterm--exit-copy-mode' (so we don't need a live vterm process) and assert the cursor moves through the full lifecycle: nil -> bar on enter, bar -> killed-local on exit. Cover all three exit paths Craig hits in normal use: - vterm-copy-mode -1 directly (the toggle) - vterm-copy-mode-done with an active region (M-w / RET) - vterm-copy-mode-done with no region (line-selection branch) - cj/vterm-copy-mode-cancel (C-g / ) Plus a multi-cycle test so a regression in `kill-local-variable' handling shows up.

fix(vterm): force a visible cursor in vterm-copy-mode

2026-05-10T08:48:44+00:00

vterm's C module sets `cursor-type' to nil whenever the underlying TUI sends DECTCEM (`\e[?25l') to hide the terminal cursor. Most full-screen TUIs do this on startup — Claude Code in an ai-vterm being a daily example. Once the cursor is hidden at the buffer level, vterm-copy-mode inherits that nil and the user can't see where point is when navigating to select text. Selection still works, but you're flying blind. Add a `vterm-copy-mode-hook' that forces `cursor-type' to a 3-pixel bar on entry and kills the buffer-local override on exit. The bar shape is drawn between characters rather than by inverting one, so heavy TUI face properties don't hide it either. On exit the live terminal goes back to whatever vterm's tracking says, so the TUI's chosen cursor state resumes. 4 ERT tests cover the hook's enter/exit behavior and confirm registration on `vterm-copy-mode-hook'.