Dictation: typing is the wrong model for multilingual users — suggest clipboard as the voxtype default

[hoblin]

Omarchy ships voxtype with mode = "type", so dictation is delivered as synthetic keystrokes. That works well in English and fails silently the moment you speak more than one language. I'd like to suggest clipboard output as the default instead, and the argument is about the model rather than about any particular driver being buggy.

A keyboard is a codec, not a channel for text

A keypress does not carry a character. It carries a position, and only a layout turns that position into a character. So typing performs an extra round trip — text → keystrokes → text — which is only lossless if sender and receiver agree on a layout.

Dictation already has the text. Routing it through a keyboard adds an encoding step that can only lose information.

One layout at a time; sentences are not

"Меня интересует context size и количество информации... Традиционные вещи отдают HTML напрямую"

Two scripts inside one sentence. No XKB layout contains both, so no layout-switching strategy — per session, per language, even per utterance — can express it. A perfect language-detection feature would still have to pick one script and mangle the rest.

This isn't an edge case. Code-switching is normal for most non-English speakers, and technical vocabulary stays in English almost everywhere.

Every type driver hits the same wall from one of two sides

A driver can either adopt a layout, or invent one. Both fail here:

driver	approach	outcome on a mixed-script sentence
wtype (current default)	generates its own synthetic keymap	corrupted — keycodes collide with real physical keys
ydotool	/dev/uinput, compositor applies the system layout	100% of Cyrillic dropped — those characters have no keycode in a us layout
dotool	/dev/uinput + assumed XKB layout	needs a per-device layout matching the script; one script at a time
eitype	libei + per-utterance layout hint	same constraint
clipboard	UTF-8 text, no keys at all	exact, 742/742 characters

Measured on Hyprland 0.56.2 with the same 742-character Russian/English sentence.

The point is that these fail for unrelated reasons. Fixing wtype would not help, because ydotool, dotool and eitype break on the layout assumption instead. It is the model that doesn't fit, not the implementation.

For completeness, the current default also has a concrete defect today: wtype assigns one keycode per distinct character starting at 9, and those collide with BackSpace, Tab, Ctrl, Shift and the F-keys, so any text with more than ~13 distinct characters loses letters. Details and reproduction: atx/wtype#71. Upstream's last commit is from 2022, so this is unlikely to be fixed there.

Why this is rarely reported

Shipped defaults are model = "base.en" and language = "en". English-only dictation rarely accumulates enough distinct characters to trip the collisions. Anyone switching to a multilingual model — which Omarchy supports and the config invites — hits it immediately, and the failure is silent: no error, just missing characters.

Suggested change

[output]
mode = "clipboard"
post_output_command = "omarchy-voxtype-paste"

with a small bin/omarchy-voxtype-paste issuing one paste through Hyprland's own key injection — the same mechanism default/hypr/bindings/clipboard.lua already uses for Universal paste, whose comment already says why a virtual keyboard is the wrong tool:

-- A virtual keyboard (wtype) won't do: the physically held SUPER merges into
-- the injected chord at the seat.

Following #6892, Ctrl+Shift+V looks like the right single chord — verified there to paste in both GUI applications and terminals, avoiding the Shift+Insert/Firefox problem. This matches the helper-script + post_output_command pattern already established by #6589.

Verified locally: exact output in both Obsidian and foot, versus corruption in every type driver.

Tradeoffs, and one conflict worth naming

• The clipboard gets clobbered. restore_clipboard exists but needs care not to race the paste; the clipboard manager also makes it recoverable.
• Paste semantics differ from typing in apps that intercept paste.
• This conflicts with Prevent voxtype focus drift during dictation output #6589. That PR adds a follow-mouse guard because synthetic typing takes ~300ms and focus can drift mid-stream. A paste is atomic, so switching to clipboard removes that failure mode rather than guarding against it. Worth deciding the direction before both land.

Pasting is also length-independent, which sidesteps a related problem: at uinput-level key delays, a long dictation takes ~30 seconds to type out.

System details

Omarchy   4.0.0-1
Hyprland  0.56.2-1
voxtype   0.7.5-1
wtype     0.4-2

---

[claude-opus-5] on behalf of hoblin

[schmunk42]

Confirming this on Omarchy 4 / Hyprland 0.56.2 with German dictation — and one detail that narrows it further: only uppercase letters break.

wtype maps the n-th distinct character to keycode n+8 (main.c:472). But a lowercase letter sitting on one of the "bad" keycodes comes through perfectly fine — it is specifically uppercase that breaks:

test string	position	result
abcdefghijklmn	n = 14th → keycode 22	unchanged
abcdefghijklmnZ	Z = 15th → keycode 23	abcdefghijklmn<TAB>
abcdefghijklmnopqrstuvwxABCDEFGH	o = 15th → 23, E = 29th → 37	o fine, E arrives as Ctrl+E (ESC[69;5u)
Der Benutzer benötigt Schreibrechte auf dem GitHub-Server in Berlin.	S = 14th → 22, c = 15th → 23	…benötigt chreibrechte … GitHub-erver … — S gone, c intact, 10/10 runs identical

The likely reason is flagged in wtype's own source, right above the line in question:

// TODO: Is including "complete" here really a good idea?
fprintf(f, "xkb_types \"(unnamed)\" { include \"complete\" };\n");

With the complete xkb types, a key whose only keysym is an uppercase letter gets type ALPHABETIC and therefore two levels — the uppercase ends up on the shift level, which wtype never presses.

The practical consequence for German (or any language that capitalises nouns) is that the lost character is almost always the first letter of a noun: uppercase letters both appear late in a sentence for the first time and are the only ones that break.

Two notes for anyone debugging this:

• type_delay_ms does nothing here. 1 / 5 / 10 / 20 / 50 ms produce bit-identical wrong output — it is not a race condition, so the "increase the delay" advice does not apply to this failure mode.
• A test string like XaXaXa… is blind to the bug (too few distinct characters) — and so is a string of 30 lowercase letters. Use a real sentence with nouns, or you will conclude the typing path is clean. It cost me two measurement rounds.

Switched to mode = "paste" with paste_keys = "ctrl+shift+v" as suggested in this thread; that fixes it. One caveat for Omarchy specifically: its own SUPER+V "universal paste" (which picks SHIFT+Insert for terminals and CTRL+V elsewhere) cannot be used as paste_keys — voxtype injects the chord through wtype, and an injected chord does not trigger the Hyprland binding. Measured: wtype -M ctrl -M shift -k v pastes, wtype -M logo -k v does nothing.

[schmunk42]

Small follow-up on a side effect of the clipboard route that is easy to miss if you run a clipboard history manager — Omarchy does, via wl-paste --watch:

restore_clipboard = true costs two history entries per dictation, not one, and the restore is not deduplicated. After two dictations my history held the same restored snippet three times in a row, interleaved with the dictated texts. With Omarchy's 300-entry historyLimit that halves the reach of the history — ~150 dictations flush it instead of 300. Setting restore_clipboard = false brings it back to one entry per dictation, and it also removes the restore_clipboard_delay_ms window in which a slow application pastes the previous clipboard instead of the dictation — wrong text rather than missing text, which is harder to notice than the bug being fixed.

Second point, worth considering upstream: voxtype does not mark its clipboard content as sensitive, so every dictation is stored in plain text in the history. Omarchy's capture.sh already honours both CLIPBOARD_STATE=sensitive and the x-kde-passwordManagerHint mime type, so a dictation containing a password would be skipped if voxtype set either. Cheap win if clipboard becomes the default output mode.