Skip to content

spec: vertical multi-caret (Alt+Up/Down, Alt+Drag) — re-spec of PR #125#133

Draft
tig wants to merge 4 commits into
developfrom
claude/spec-pr-125-reimplementation-rVWsC
Draft

spec: vertical multi-caret (Alt+Up/Down, Alt+Drag) — re-spec of PR #125#133
tig wants to merge 4 commits into
developfrom
claude/spec-pr-125-reimplementation-rVWsC

Conversation

@tig
Copy link
Copy Markdown
Member

@tig tig commented May 15, 2026

Summary

Adds specs/vertical-multi-caret/spec.md. No code changes.

PR #125 ships the right user-facing feature set — Alt+Up / Alt+Down to create vertically-aligned carets, Alt+Drag to create a column, Tab at every caret, normalization so the primary moving onto an additional caret doesn't duplicate edits, and Ctrl+Click after a vertical block landing where the user clicked — but the maintainer rejected it as hacky after a stream of regressions kept popping out under each fix:

@copilot this is basically non-functional. The first time I use it, it basically works. But then all cursor/caret management is messed up.

…and four follow-ups, ending with the unresolved "primary caret disappears after exiting multi mode" that Copilot couldn't reproduce.

This spec treats PR #125's tests as the executable contract and re-derives the requirements / file scope / definition of done from black-box behavior, not from the patch. The intended workflow is: open a new branch from develop, port the PR #125 tests verbatim, confirm they fail, then implement against this spec.

What the spec covers

  • 12 user scenarios extracted from the PR test set, plus the unresolved "caret disappears" bug as Scenario 12 / OD-1.
  • 17 requirements (FR-001 … FR-017) covering Alt+Up/Down, Alt+Drag, sticky visual column (incl. tabs and wrap), normalization on every caret-offset / document-change boundary, Tab-at-all-carets with single-undo, Esc semantics, Ctrl+Click reorder defense, primary-caret visibility post-exit, and the visual-line cache invalidation defect Scenario 10 exposes.
  • Out-of-scope: column-selection variants (Alt+Shift+arrow), find/replace across multi-caret, ted UI menu items, WordWrap-toggle reflow.
  • Three open decisions: OD-1 (caret-disappears repro), OD-2 (Alt+Shift+arrow reservation), OD-3 (whether ClearAdditionalCarets should drop to internal per R9).

What this PR is not

Test plan

https://claude.ai/code/session_014uBfGKbouM7qvzSShb3WCc


Generated by Claude Code

claude added 4 commits May 15, 2026 18:41
PR #125 ships the right user-facing feature set (Alt+Up/Down for
vertically-aligned carets, Alt+Drag for column-of-carets, Tab at all
carets, normalization on primary-caret moves, Ctrl+Click after vertical
block) but the implementation accreted around maintainer-reported
regressions and is rejected as throwaway. This spec captures the
behavior from the PR's tests, lifts the failing-first regressions as
acceptance criteria, and flags the open caret-disappears-after-exit bug
as OD-1 to be reproduced before the spec moves to Ready.
Cross-walk every user-facing behavior in the spec against VS Code and
VS 2022/2026. Call out the three intentional divergences (Alt vs Ctrl+Alt
vs Alt+Shift for add-caret-above/below; Alt+drag carets-only vs
Shift+Alt+drag column-select; Ctrl+Click vs Alt+Click for caret-at-click)
with rationale. Add OD-4 (keybinding choice) and OD-5 (Alt+Click alias).
Resolve OD-4 in favor of matching VS Code chords (modulo terminal
incompat): Ctrl+Alt+Up/Down for add-caret-above/below, Shift+Alt+drag
modifier for the column-drag. Comparison table rows that previously
diverged on chords now match. The Shift+Alt+drag-produces-carets-only
divergence stays (column-select-per-row is the follow-up); Ctrl+Click
vs Alt+Click stays as a separate open question.

Rename requirements from cryptic FR-### identifiers to human-readable
labels (e.g. "Add caret above", "Caret normalization", "Cache
invalidation on offset shift"). Open Decisions and scenarios are
referenced by name throughout. Tests renamed from AltDown_* /
AltDrag_* to CtrlAltDown_* / ShiftAltDrag_*.

Add Resolved Decisions section capturing the keybinding choice and a
new open question for whether ted should ship an alternate-chord
fallback for terminals/WMs that grab Ctrl+Alt+arrow.
Resolve the alternate-chord open question: no editor-specific fallback.
Keys are fully adjustable via TG keybindings, so pre-ship per-platform
defaults the TG-standard way — a [ConfigurationProperty]
DefaultKeyBindings populated from a PlatformKeyBinding record
(All/Windows/Linux/Macos), user-overridable through View.ViewKeyBindings
config. Windows/Linux default to the VS Code chord (Ctrl+Alt+Up/Down);
the macOS default is a wiring-time empirical question (Terminal.app /
iTerm2 swallow Cmd and may not deliver Ctrl+Alt+arrow) tracked as a
remaining open decision. References TG docfx/docs/keyboard.md for the
binding-layer model and Bind.AllPlus() helper.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants