Diktování, které přežije terminál

Vývojáři, kteří zkoušejí diktovací nástroje, často narazí na selhání s velmi konkrétním tvarem. V ukázce nástroj funguje krásně. Funguje v Poznámkách, na Slacku, v prohlížeči. Pak zaostříte terminál, nadiktujete větu a buď se neobjeví nic, nebo se objeví něco jiného, než jste řekli, nebo se objeví polovina a druhá půlka je záhadně ve schránce. Někdy to funguje lokálně a umře to ve chvíli, kdy se přes SSH připojíte na stroj.

Ten vzorec je dost konzistentní na to, abych si nemyslel, že jde o chybu v jednom jediném produktu. Je to důsledek toho, jak celá kategorie vkládá text — a selhává přesně na místech, kde vývojář žije.

Dneska na tom záleží víc než před dvěma lety. Pokud řídíte Claude Code hlasem — postup, který jsem popsal v článku Řízení Claude Code hlasem — pak terminál není jedna aplikace z mnoha. Je to ta aplikace. Tam přistávají vaše prompty, tam vaši agenti čekají na přesměrování, tam celá věc s paralelními dráhami buď funguje, nebo ne. Diktovací nástroj, který je v terminálech vrtkavý, je pro vibe codera vrtkavý ve své jediné práci.

Proč se vkládání láme přesně tam, kde vývojáři žijí?

Tady je mechanika na úrovni celé kategorie. Většina diktovacích nástrojů vkládá text stejně: přepsanou větu položí do systémové schránky a pak v aktivní aplikaci nasyntetizuje stisk Cmd+V. Je to rozumné výchozí nastavení — vkládání je okamžité, funguje skoro v každém grafickém textovém poli a nevyžadovalo skoro žádné inženýrství pro jednotlivé aplikace.

Problém je všechno to, na čem ten předpoklad potichu stojí.

Stojí na tom, že aktivní aplikace bere Cmd+V jako „vlož“. Terminály to tak často neberou — mnohé používají Cmd+V na něco jiného nebo vůbec na nic, tmux a vim mají vlastní představy o tom, co vkládání znamená, a vzdálená SSH session může dávku vloženého textu interpretovat způsobem, který lokální stroj nepředpovídá. Bracketed paste, copy-mode, insert-mode versus normal-mode: terminálový svět je plný stavů, ve kterých syntetické vložení přistane špatně nebo nepřistane vůbec.

Stojí na tom, že schránka je dostupná a nehlídaná. Správci schránky ji přepisují. Správci hesel ji záměrně čistí nebo chrání — bezpečnostní funkce, která z „vlož mi nadiktované“ udělá „nevlož nic“, a to tiše. A i když všechno funguje, nástroj právě přepsal to, co jste měli zkopírované. SHA commitu, které jste nesli mezi okny, je pryč a nahradila ho vaše vlastní věta. Pro člověka, který žongluje s několika dráhami, to není škrábnutí; schránka dělala nějakou práci.

A stojí to — tohle lidi překvapuje nejvíc — na rozložení vaší klávesnice. Když se nástroj uchýlí k simulaci stisků kláves, naivní způsob je posílat kódy kláves: fyzické pozice kláves. Kódy kláves se mapují na znaky přes vaše rozložení. Na QWERTY vyprodukuje kód pro „V“ písmeno V. Na Dvoraku je stejná fyzická pozice jiné písmeno. Takže nástroj, který simuluje scan kódy na rozložení Dvorak, AZERTY nebo Colemak, vyprodukuje text, který vypadá, jako by prošel substituční šifrou. Uživatelé hlásí blábol a předpokládají, že selhalo rozpoznávání řeči. Neselhalo — řeč byla dokonalá, zamotalo ji vkládání.

Nic z toho není zlá vůle ani lenost. Vkládání ze schránky je správné výchozí nastavení pro 90 % případů. Jenže vývojáři tráví den v těch zbylých 10 %.

Co ve skutečnosti znamená „napiš to místo toho“

Keebye má nastavení insert_mode se dvěma hodnotami: paste, což je výchozí, a type.

Režim psaní nevkládá. Na macOS používá CGEventKeyboardSetUnicodeString — API, které k syntetické klávesové události připojí skutečný text v Unicode. Znak nese sama událost, nedohledává se přes rozložení klávesnice. Tím je z principu nezávislý na rozložení: Dvorak, AZERTY, Colemak, na čemkoli píšete, dorazí text, který byl přepsán, protože nikdy nedošlo k překladu ze scan kódu na znak, který by mohl dopadnout špatně.

Druhá vlastnost režimu psaní je ta, na které uživatelům terminálu záleží: nikdy nesáhne na schránku. Na této cestě kódu nula operací se schránkou. Obsah vaší schránky zůstává váš — SHA přežije, správce hesel nemá proti čemu bránit, správce schránky nemá co logovat.

A protože se terminály a vzdálené session mohou zadrhnout na textu, který přichází rychleji, než píše kterýkoli člověk, drží si režim psaní záměrně tempo: text jde dovnitř po částech o 16 znacích s mezerou 4 milisekundy mezi částmi. Dost rychle na to, aby věta přistála výrazně pod sekundu; dost uměřeně na to, aby ji panel tmuxu přes SSH přijal jako stisky kláves, kterým stačí, a ne jako blok, který musí interpretovat.

Režim vkládání tu pořád je a pořád je výchozí, protože je pro velké bloky textu v běžných grafických aplikacích opravdu rychlejší — zpráva na Slacku o třech odstavcích dorazí jako jedno vložení, ne jako proud částí. I režim vkládání si ale odnesl lekci o rozloženích: syntetické Cmd+V používá fyzický kód klávesy V, takže se samotné vkládání na jiných než QWERTY rozloženích neláme tak, jak se to může stát přístupům založeným na dohledávání znaků.

Praktické nastavení pro práci s agenty je jednoduché: přepněte insert_mode na type, zaostřete terminál, ve kterém běží Claude Code, podržte klávesu, řekněte přesměrování, pusťte. Prompt dorazí tak, jak by dorazily stisky kláves, protože pokud jde o terminál, jsou to přesně ony. Krok za krokem popsanou verzi tohoto nastavení, včetně specifik pro SSH a tmux, najdete v článku hlasové diktování do terminálu na macOS.

Upřímné limity

Režim psaní je u dlouhého textu pomalejší než vkládání — to je aritmetika, ne vada. Stisky kláves po částech s mezerami na udržení tempa trvají déle než jediná událost vložení, a pokud diktujete několik odstavců do dokumentu, režim vkládání vám bude připadat svižnější. Přesně proto zůstává vkládání výchozí a režim psaní je něco, do čeho se v nastavení pustíte vědomě; správný režim závisí na tom, kam váš text míří.

Některé aplikace syntetický vstup omezují nebo filtrují, obvykle z bezpečnostních důvodů, a žádná strategie vkládání tomu úplně neunikne — aplikace, která odmítá syntetické události, je odmítne od každého diktovacího nástroje.

A abych byl jasný v tom, co tento článek tvrdí a co ne: stížnost na to, že se vkládání v terminálech láme, je vzorec napříč diktovací kategorií, ne vada jedinečná pro nějakou konkurenci. Jiné nástroje mají vlastní odpovědi a vlastní silné stránky — napsali jsme upřímná srovnání Keebye vs Superwhisper a Keebye vs Wispr Flow, včetně toho, kde vám každý z nich může sednout líp.

Vkládání je ta neefektní půlka diktování

Všechnu pozornost sbírá rozpoznávání řeči — názvy modelů, tvrzení o přesnosti, počty jazyků. Jenže diktovací nástroj má dvě práce: slyšet vás správně a pak dostat text tam, kde je váš kurzor, aniž by ho ztratil nebo zdeformoval. Ta druhá práce zní triviálně a je to místo, kde kategorie vývojáře potichu zklamává, protože ta druhá práce je snadná v TextEditu a těžká v panelu tmuxu na vzdáleném stroji pod rozložením Dvorak.

Pokud vaše prompty přistávají v terminálech — a pokud řídíte agenty na psaní kódu, tak přistávají — není vkládání poznámkou pod čarou. Je rozdílem mezi nástrojem, který předvádíte, a nástrojem, který používáte. Příbuzné způsoby selhání mají mimochodem stejnou příchuť: první slovo diktování, které sežere studený start mikrofonu, je další stížnost napříč celou kategorií s mechanickým vysvětlením a sepsali jsme ji v článku Proč diktovací aplikace sežerou vaše první slovo.

Keebye je v předběžném přístupu pro macOS. Pokud vám někdy zmizelo diktování někde mezi vašimi ústy a terminálem, spusťte níže bezplatnou zkušební verzi, zapněte režim psaní a zkuste stejný prompt znovu. Vaše zkopírované SHA zůstane ve schránce, zatímco slova dorazí jako napsaný Unicode.