feat(shortcuts): keys for the two column verbs, and a better rule for why

[PathGao]

#652 left both column verbs palette-only. Reaching one is Cmd+P, then typing the command's name, then Enter — three steps, and you have to remember what it is called.

verb	chord	why it earns one
Insert Column	Mod+Shift+C	mid-frequency, fiddly by hand
Delete Column	Mod+Shift+Backspace	no manual fallback at all

The rule changed, so the old one is deleted rather than parked

TABLE_VERBS_WITHOUT_A_CHORD said, in effect, destructive table verbs get no keys, because a mis-fire costs too much. That cannot have been the rule being applied — Delete Column destroys strictly more than Delete Row, and it is the one getting a key.

The distinction that actually holds is whether the user can already do it without us:

Delete Row      put the caret on the line, select it, delete       → trivial by hand
Delete Column   edit the pipes on every row without slipping once  → effectively impossible

So Delete Column earns a key because there is no fallback; Delete Row does not, because a key buys nothing over what its user can already do. TABLE_VERBS_WITHOUT_A_CHORD is down to that one row, and the WHY THE DESTRUCTIVE PAIR HAS NO CHORD block in Editor.svelte was rewritten to match — including that its original hazard is gone in fact, since Mod+Shift+K is unbound and the Mod+K namespace no longer exists.

An "the asymmetry is itself a protection" paragraph added in an earlier round was removed, not amended: it argued the rule that has now been replaced, and leaving it would have been two rules standing side by side.

Why Backspace, when Mod+Shift+D is also free

Physical non-adjacency. D sits next to C; one slip would turn "insert a column" into "delete a column". A destructive verb should not neighbour its constructive counterpart — the same shape as the original complaint that Mod+K Shift+R sat one slip from Monaco's delete-line. Backspace is across the keyboard and already means "remove" everywhere.

That Mod+Shift+D is free is stated at the binding, so the next reader sees it was rejected deliberately rather than overlooked. Also noted there: the new chord's nearest neighbour is Mod+Backspace (deleteAllLeft), one modifier away — an ordinary undoable edit rather than a structural one, so it does not disqualify the chord, but "one slip from" is the exact hazard class this rework is about and it belongs on the record.

Two of my premises were wrong

I claimed Mod+Shift+Delete was taken by clipboard.js and Mod+Shift+Y by editorExtensions.js. Both are free on all three platforms. clipboard.js binds Shift+Delete with no Mod — and per its own header binds nothing at all in a browser, since isNative is false in a WebView. Ctrl+Y is redo on Windows and Linux, but without Shift.

So Backspace was not forced by elimination. It stands on the adjacency argument above, which is the reason that was actually being applied.

Mod+Alt+C stays recorded

Above DELIBERATE_OVERRIDES, where the next chord hunt starts. toggleFindCaseSensitive is a registerEditorCommand, not a registerEditorAction, so it has no command palette entry — taking its chord would leave it reachable only by clicking the Aa button, breaking the contract every override row rests on.

Extended past that one command: toggleFindWholeWord, toggleFindRegex and toggleFindInSelection are registered identically and are disqualified for the same reason, so nobody has to work through them one at a time.

On coverage

No new test() was added, and none was needed: the registry↔editor contract test is parameterised over SHORTCUTS, so adding a row is adding per-platform coverage. That is what produced the red.

macOS: the registry says table-insert-column has a shortcut, but
Editor.svelte registers no keybinding for that action id
table-insert-column has no chord, so the panel must not claim one

Same pair for table-delete-column.

npm test 903 · vitest 357 · check 0 errors.

🤖 Generated with Claude Code