Dictation: deliver dictated text as keyboard input, not as a paste

[sghng]

What do you want to change?

macOS dictation should reach terminal apps through the same channel as keyboard input. Today the live transcript is rendered as a preedit overlay, and on commit the entire transcript is delivered to the app as a single raw blob (or as bracketed paste, for clipboard-based dictation tools). I'd like Ghostty to stream the dictation's marked-text updates to the app — via the kitty keyboard protocol's preedit events (10 = preedit start, 11 = preedit end, 12 = preedit commit, 13 = preedit update), or by relaying incremental text — so TUI apps receive dictated text through their normal input path: word by word, revisable, exactly like typing.

Why do you want to make this change?

I work on opencode, a TUI coding agent, and I've been chasing this from the app side. My conviction: voice input is an extension of the keyboard — dictated text and typed text should be indistinguishable to the app.

The problem has two parts, and fixing the first one doesn't help:

1. The preview doesn't wrap. During dictation the live transcript renders as a single-line preedit that scrolls off-screen for long sentences. Multi-line preedit (Preedit text should support multiple lines of input #2502) would make the preview look right — but that's cosmetic.
2. The commit is a blob. When dictation ends, the whole transcript hits the app at once. Whatever the app does for pastes, it does to your dictated text: opencode collapses large pasted blocks into a [Pasted ~N lines] chip (dictated text was being collapsed — we had to add a prose heuristic to keep it inline), other TUIs apply bracketed-paste assumptions, auto-indent, line-length truncation. Every downstream app accumulates its own hack, and each hack exists only because the terminal delivered voice input as something other than keyboard input.

So multi-line preedit is not the fix. Even perfectly wrapped, the TUI still receives one big block on commit and still treats it as a paste. The only change that makes dictation actually behave like typing is to deliver it like typing: stream the marked text so it arrives through the input path, renders inline in the app's own text component, and revisions replace the marked range like any IME. The kitty preedit events are the standard mechanism for exactly this — and they benefit all IME users, not just dictation.

Why this matters now: coding agents are a big reason terminal emulators are heating up again, and voice input (built-in dictation, Wispr, SuperWhisper, Typeless…) is a primary input method for a growing share of those users, for accessibility reasons and otherwise. Downstream apps keep getting more input-sensitive, and the paste/typed distinction keeps leaking into experiences where it shouldn't exist.

Related

• Dictation mode does not show text in real-time in Ghostty [macOS] #2473 — dictation real-time display (resolved)
• Preedit text should support multiple lines of input #2502 — single-line preedit limitation (open, currently "intended")
• Support Voice Dictation Mode on Macos #13006, macOS: voice control dictation does not work in Ghostty #8717 — existing dictation demand
• Incorrect dictation after comma on macbook #11077 — dictation + manual punctuation divergence from Terminal.app

I'm happy to do the app-side work (opencode/opentui consuming the preedit events), test end-to-end, and iterate.

[jcollie]

!vouch

[jcollie]

Note that we a preparing 1.4 for release so this won't be merged before then. I'd also recommend splitting this work up into multiple smaller PRs to make reviewing easier.