Batch emission means the whole text is injected right after the key
is released, when the target TUI is idle, and zero delay landed every
character in testing (2ms was whisrs's default, 10ms my earlier
anti-drop experiment — both just made the text trickle out slowly for
no benefit here).
Streaming typed every phrase as soon as a 250ms pause came along,
which made long dictations trickle in slowly and double-emitted the
last phrase (once as the phrase, once in the final flush — the source
of the phantom "Thank you."). With phrase_silence_ms at 5s, phrases
only flush at the very end, so the whole text lands in one piece
about 0.1s after the key is released. The 20s force-split still
emits during very long continuous speech, so nothing is lost there.
Streaming dictation only emits a phrase after phrase_silence_ms of
silence; the 400ms default stalled long continuous speech until the
20s force-split, which read as "the text cuts off". 250ms emits at
short breathing pauses instead.
key_delay_ms was the 2ms default, which drops characters in busy
Node/Ink TUIs like the pi chat while they are streaming output;
10ms keeps dictation readable there.
The default 2s auto-stop ended dictations whenever a thinking pause ran
a little long while the key was still held. 6s keeps room to think
while still bounding a lost-release recording (the guards make missed
releases rare, so the longer bound costs little).
Keep the dictation daemon config versioned with the rest of the setup.
The file carries no secrets (local backend), but if a cloud backend with
an API key is ever configured it must not be committed; whisrs accepts
WHISRS_GROQ_API_KEY-style env vars instead.
