feat(prompt): selection at a prompt types over and deletes

[DananzMolt]

Stacked on #3. Base is ivrix-bidi-hyphen-fix; retarget to ivrix-hebrew-font once that merges.

What

Select text at a prompt, type, and the selection is replaced. Press backspace or delete and it is removed. Editor behaviour, at the shell.

How, and why it looks like this

There is no terminal protocol for this. The selection lives entirely in the terminal, the shell has never heard of it, and no escape sequence expresses "replace the selection". Every terminal that appears to do this is either an application implementing its own editor (Claude Code, vim) or is not doing it at all.

So it is emulated on the mechanism cursor-click-to-move already uses:

1. arrow keys to move the cursor to the start of the selection
2. one forward delete per selected position
3. the original key encodes as normal, inserting where the selection was

Backspace and delete are consumed at step 3 instead, since removing the selection is already what they asked for. The full sequence is one write, not one message per keystroke, so the shell cannot redraw partway through and invalidate the counts.

New Screen.promptInputCellCount counts editable positions using exactly the accounting promptClickMove uses, so the delete count is directly comparable to the arrow count. That equivalence is the whole correctness argument.

Deliberately gated off

Acting on a selection the terminal cannot verify would corrupt the user's command line, so each of these bails rather than guessing:

• no OSC 133 shell integration advertising cl (a click_events shell has no ranged-delete equivalent)
• cursor not on input. This one is subtle: promptClickMove returns no-movement both when it succeeds trivially and when it refuses, and deleting on the second would delete from wherever the cursor happens to be
• either selection end outside the current prompt's input, so command output and older prompts stay copy-only
• rectangle selections, which are not a run of input positions
• an application owning the screen
• right-to-left rows. A visually contiguous selection on a Hebrew row is not a contiguous run of logical positions. Enabling it there without the visual-to-logical mouse map would delete the wrong text

Config: selection-edit-at-prompt, default true.

Prerequisite fix, separate commit

promptClickMove counted screen cells, but a wide character is two cells and one editor position, so clicking past CJK or emoji emitted an extra arrow per wide character and overshot. This is an upstream ghostty bug, not an Ivrix one, but it had to be fixed here or the delete count would not match the arrow count.

Known limitation

zsh-autosuggestions and similar render ghost text into cells that are not in the edit buffer. A selection extending into that region counts cells the shell will not delete. Documented in the config docs and the commit message; no way to detect it from the screen alone.

Verification

filter	result
prompt selection edit	74/74
promptInput	76/76
promptClickMove	90/90
bidi	109/109

Baseline with a filter matching nothing is 72, so the new tests genuinely execute rather than being silently skipped.

New coverage: 4 promptInputCellCount cases (inclusive range, prompt cells excluded, wide character counted once, reversed range), 1 wide-character promptClickMove case, 2 key-classifier cases covering text, shift, backspace, delete, repeat, ctrl/alt/super, arrows, enter, tab, escape.

The runtime path in Surface.maybePromptSelectionEdit is not unit-testable without a Surface harness, so it is covered by construction and dogfood. That is the weak spot in this PR.

zig build test unfiltered still does not compile on this line, from the same pre-existing src/font/shaper/coretext.zig:1360 break noted in #3.

Submodule

ghostty f64bbae..6dda887, pushed to DananzMolt/ghostty as ivrix-prompt-selection-edit.

https://claude.ai/code/session_01TPRwsvsc1t88Wg5LaJ3rXb

[DananzMolt]

Follow-up: it was inert on fish, and the obvious fix was also wrong

Dogfood found the feature did nothing. Two bugs.

1. Wrong gate. The original commit required the shell to advertise the OSC 133 cl click option. zsh does via cmux's integration; fish 4 advertises click_events=1 instead, and the code bailed on that branch. Every fish user got nothing at all.

2. Supporting click_events would not have fixed it either. Before adding that branch I injected the exact byte sequence into a live fish 4.6 prompt to check the mechanism:

ESC[<0;12;3M  ESC[3~ x4      ->  "echo AAAABBBBCCCC[<0;12;3M"   (click ignored, escape body inserted as text)
ESC[D x8      ESC[3~ x4      ->  "echo AAAACCCC"                (arrows + deletes work)

Fish consumes the escape and inserts the remainder literally. It advertises click handling it does not honor for an injected event. Shipping the "obvious" fix would have produced a second dud.

Fix: stop asking the shell where to put its cursor. The terminal already knows the distance in input cells, and arrow keys are understood by every line editor. New Screen.promptLineMove always computes the arrow motion; promptClickMove keeps deferring to click_events shells, which is correct for an actual click, so the shipped click path is untouched.

This also drops the click-option requirement entirely. All the feature needs now is OSC 133 B input marking, so it works on shells that mark input but advertise no click support at all. The config docs are updated accordingly.

New tests assert the bug directly: for a click_events screen, promptClickMove returns zero while promptLineMove still returns the correct motion, in both directions.

filter	result
promptLineMove	74/74
prompt selection edit	74/74
promptInput	76/76
promptClickMove	90/90

Baseline for a filter matching nothing is 72.

Worth noting for separate triage: ghostty's own cursor-click-to-move very likely does not work on fish either, for the same reason. That is upstream behaviour and out of scope here.

ghostty 6dda887..89127d8.