mirror of
https://github.com/stablyai/orca.git
synced 2026-10-23 08:03:39 +00:00
Neil
2bf7d44f65
macOS rewrites a double space into ". " while the user is typing at a shell prompt. Terminal.app, iTerm2, Ghostty and Warp all ignore this; Orca is the only one that reacted to it, and it reacted by losing the keystroke entirely. The pty received "ab " where every other terminal sends "ab ". forwardCommittedText retired the pending commit on any non-insertText input, so the deleteContentBackward half settled the claim with nothing and the replacing insertText that followed found no claim and returned. Zero bytes for the whole keystroke, and xterm never saw the keydown either because the forwarder had already claimed it. A deletion no longer retires the claim, and a keystroke the text system rewrote delivers the character the key produced rather than the replacement. Two spaces stay two spaces, "--" stays "--", and a text replacement like "omw " stays "omw ". The discriminator is structural rather than a list of characters: a one-key-one-character substitution from an input source never deletes first. So layout substitution keeps working untouched - the backslash-position case, full-width digits, telex - while the text-editing rules that rewrite what is already on the wire are declined. That distinction is what the file previously lacked, and it conflated the two. Declining is the whole fix, so the retraction accounting an earlier pass added is gone with the module that held it. The forwarder ends up smaller than it started. autocorrect, autocapitalize and spellcheck are already off on the helper textarea and do not prevent this; they govern the browser's own correction, not the system replacement service. A native terminal escapes by not being a text view, which a browser-based one cannot do. Coverage for the boundary is restored headlessly, as CDP-synthesised arms on the normal shards asserting bytes the pty child receives. Refs #11504