Dictatie die de terminal overleeft

Developers die dictatietools proberen lopen vaak tegen een storing met een heel specifieke vorm aan. De tool werkt prachtig in de demo. Hij werkt in Notities, in Slack, in de browser. Dan geef je een terminal focus, dicteer je een zin, en verschijnt er ofwel niets, ofwel iets wat je niet hebt gezegd, ofwel de helft — terwijl de andere helft nu op mysterieuze wijze in je klembord zit. Soms werkt het lokaal en sterft het op het moment dat je via SSH een machine binnengaat.

Het patroon is consistent genoeg dat ik niet denk dat het een bug in één product is. Het is een gevolg van hoe de categorie tekst invoegt — en het faalt precies op de plekken waar een developer leeft.

Dat weegt nu zwaarder dan twee jaar geleden. Stuur je Claude Code met je stem aan — de workflow die ik beschreef in Claude Code aansturen met je stem — dan is de terminal niet één app tussen vele. Het is dé app. Daar landen je prompts, daar wachten je agents op bijsturing, daar werkt dat hele parallelle-lanes-verhaal wel of niet. Een dictatietool die wispelturig is in terminals is voor een vibecoder wispelturig in zijn enige taak.

Waarom breekt plakken precies waar developers leven?

Dit is het mechanisme op categorieniveau. De meeste dictatietools voegen tekst op dezelfde manier in: ze zetten je getranscribeerde zin op het systeemklembord en synthetiseren vervolgens een Cmd+V-toetsaanslag bij de app met focus. Het is een verstandige standaard — plakken is instant, het werkt in vrijwel elk grafisch tekstveld, en er was nauwelijks engineering per app voor nodig.

Het probleem is alles waar die aanname stilletjes van afhangt.

Het hangt ervan af dat de app met focus Cmd+V als "plakken" behandelt. Terminals doen dat vaak niet — veel gebruiken Cmd+V voor iets anders of voor niets, tmux en vim hebben hun eigen ideeën over wat plakken betekent, en een remote SSH-sessie kan een salvo geplakte tekst interpreteren op manieren die de lokale machine niet kan voorspellen. Bracketed paste, copy-mode, insert-mode versus normal-mode: de terminalwereld zit vol toestanden waarin een synthetische plakactie verkeerd of nergens landt.

Het hangt ervan af dat het klembord beschikbaar en onbewaakt is. Klembordmanagers herschrijven het. Wachtwoordmanagers wissen of beschermen het opzettelijk — een beveiligingsfunctie die "plak mijn dictatie" verandert in "plak niets", zonder melding. En zelfs wanneer alles werkt, heeft de tool net overschreven wat je had gekopieerd. De commit-SHA die je tussen vensters meedroeg is weg, vervangen door je eigen zin. Voor iemand die meerdere lanes jongleert is dat geen schrammetje; het klembord deed een taak.

En het hangt af — en dit is degene die mensen verrast — van je toetsenbordindeling. Wanneer een tool terugvalt op het simuleren van toetsaanslagen, is de naïeve manier om keycodes te sturen: de fysieke toetsposities. Keycodes worden via je indeling naar tekens vertaald. Op QWERTY levert de code voor "V" een V op. Op Dvorak is diezelfde fysieke positie een andere letter. Een tool die scancodes simuleert op een Dvorak-, AZERTY- of Colemak-indeling produceert dus tekst die eruitziet alsof ze door een substitutiecijfer is gehaald. Gebruikers melden brabbeltaal en nemen aan dat de spraakherkenning faalde. Dat was niet zo — de spraak was perfect, het invoegen heeft het door elkaar gegooid.

Niets hiervan is kwade wil of luiheid van wie dan ook. Klembord-plakken is de juiste standaard voor de 90%-situatie. Alleen brengen developers hun dag door in de andere 10%.

Wat "typ het gewoon" werkelijk betekent

Keebye heeft een instelling genaamd insert_mode met twee waarden: paste, de standaard, en type.

De typmodus plakt niet. Op macOS gebruikt hij CGEventKeyboardSetUnicodeString — een API die de daadwerkelijke Unicode-tekst aan een synthetisch toetsevent hangt. Het teken wordt in het event zelf meegedragen, niet opgezocht via je toetsenbordindeling. Dat maakt hem indelingsonafhankelijk van constructie: Dvorak, AZERTY, Colemak, waarop je ook typt, de tekst die aankomt is de tekst die is getranscribeerd, want er was nooit een vertaling van scancode naar teken die fout kon gaan.

De tweede eigenschap van de typmodus is degene waar terminalgebruikers om geven: hij raakt het klembord nooit aan. Nul klembordbewerkingen op dat codepad. Je klembordinhoud blijft van jou — de SHA overleeft, de wachtwoordmanager hoeft zich nergens tegen te wapenen, de klembordmanager heeft niets te loggen.

En omdat terminals en remote sessies zich kunnen verslikken in tekst die sneller aankomt dan een mens ooit typt, doseert de typmodus zichzelf bewust: tekst gaat erin in blokjes van 16 tekens met 4 milliseconden tussenruimte. Snel genoeg dat een zin ruim binnen een seconde landt; afgemeten genoeg dat een tmux-paneel over SSH hem ontvangt als toetsaanslagen die het kan bijhouden, en niet als een blok dat het moet interpreteren.

De plakmodus is er nog steeds, en nog steeds als standaard, omdat hij echt sneller is voor grote blokken tekst in gewone grafische apps — een Slack-bericht van drie alinea's komt aan als één plakactie in plaats van een stroom blokjes. Ook de plakmodus heeft de indelingsles geleerd: de synthetische Cmd+V gebruikt de fysieke V-keycode, dus plakken zelf breekt niet op non-QWERTY-indelingen zoals benaderingen met tekenopzoeking dat kunnen doen.

De praktische setup voor agentwerk is simpel: zet insert_mode op type, geef de terminal met Claude Code focus, houd de toets ingedrukt, spreek de bijsturing in, laat los. De prompt komt aan zoals toetsaanslagen dat zouden doen, want voor zover de terminal het kan zien, is dat ook wat ze zijn. Een stap-voor-stap-versie van deze setup, inclusief de SSH- en tmux-specifieke details, staat in spraakdictatie voor de macOS-terminal.

De eerlijke grenzen

De typmodus is langzamer dan plakken bij lange tekst — dat is rekenkunde, geen defect. Blokjes toetsaanslagen met doseringspauzes duren langer dan één plak-event, en dicteer je meerdere alinea's in een document, dan voelt de plakmodus vlotter. Precies daarom blijft plakken de standaard en is de typmodus iets waar je in de instellingen voor kiest; de juiste modus hangt af van waar je tekst naartoe gaat.

Sommige applicaties beperken of filteren synthetische invoer, meestal om veiligheidsredenen, en geen enkele invoegstrategie ontsnapt daar volledig aan — een app die synthetische events weigert, weigert ze van elke dictatietool.

En om duidelijk te zijn over wat dit artikel wel en niet beweert: de klacht dat plakken breekt in terminals is een patroon in de hele dictatiecategorie, geen defect dat uniek is voor een concurrent. Andere tools hebben hun eigen antwoorden en hun eigen sterke punten — we schreven eerlijke vergelijkingen in Keebye vs Superwhisper en Keebye vs Wispr Flow, inclusief waar elk van hen beter bij jou zou kunnen passen.

Invoegen is de onglamoureuze helft van dictatie

Spraakherkenning krijgt alle aandacht — modelnamen, nauwkeurigheidsclaims, aantallen talen. Maar een dictatietool heeft twee taken: je correct verstaan, en daarna de tekst bij je cursor krijgen zonder hem kwijt te raken of te verminken. De tweede taak klinkt triviaal en is waar de categorie stilletjes faalt voor developers, want de tweede taak is makkelijk in TextEdit en lastig in een tmux-paneel op een remote machine onder een Dvorak-indeling.

Landen jouw prompts in terminals — en stuur je codeeragents aan, dan doen ze dat — dan is invoegen geen voetnoot. Het is het verschil tussen een tool die je demonstreert en een tool die je gebruikt. Verwante faalpatronen hebben trouwens dezelfde smaak: dat het eerste woord van een dictatie wordt opgegeten door een koude start van de microfoon is nog zo'n categoriebrede klacht met een mechanische verklaring, en die hebben we opgeschreven in waarom dictatie-apps je eerste woord opeten.

Keebye is in early access voor macOS. Is jouw dictatie ooit ergens tussen je mond en een terminal verdwenen, start dan hieronder je gratis proefperiode, schakel de typmodus in en probeer dezelfde prompt opnieuw. Je gekopieerde SHA blijft op het klembord staan terwijl de woorden als getypte Unicode aankomen.