Diktovanie, ktoré prežije terminál

Vývojári, ktorí skúšajú nástroje na diktovanie, často narazia na zlyhanie s veľmi konkrétnym tvarom. V ukážke nástroj funguje nádherne. Funguje v Poznámkach, v Slacku, v prehliadači. Potom zaostríte terminál, nadiktujete vetu a buď sa neobjaví nič, alebo sa objaví niečo, čo ste nepovedali, alebo sa objaví polovica a druhá polovica je záhadne vo vašej schránke. Niekedy to funguje lokálne a zomrie vo chvíli, keď sa cez SSH pripojíte na server.

Tento vzorec je dosť konzistentný na to, aby som si nemyslel, že ide o chybu jedného produktu. Je to dôsledok toho, ako celá kategória vkladá text — a zlyháva presne na miestach, kde vývojár žije.

Dnes to hrá väčšiu rolu než pred dvomi rokmi. Ak riadite Claude Code hlasom — pracovný postup, ktorý som opísal v texte Riadenie Claude Code hlasom —, potom terminál nie je jednou aplikáciou z mnohých. Je tou aplikáciou. Je to miesto, kam pristávajú vaše prompty, kde vaši agenti čakajú na korekcie, kde celá tá vec s paralelnými dráhami buď funguje, alebo nie. Nástroj na diktovanie, ktorý je v termináloch nespoľahlivý, je pre vibe codera nespoľahlivý v jedinej práci, ktorú má.

Prečo sa vkladanie láme presne tam, kde vývojári žijú?

Tu je mechanika na úrovni kategórie. Väčšina nástrojov na diktovanie vkladá text rovnako: prepísanú vetu položia do systémovej schránky a potom v aktívnej aplikácii nasyntetizujú stlačenie Cmd+V. Je to rozumné predvolené nastavenie — vkladanie je okamžité, funguje takmer v každom textovom poli s grafickým rozhraním a nevyžiadalo si takmer žiadne inžinierstvo pre jednotlivé aplikácie.

Problémom je všetko, na čom tento predpoklad potichu závisí.

Závisí na tom, že aktívna aplikácia berie Cmd+V ako „vložiť“. Terminály to často nerobia — mnohé používajú Cmd+V na niečo iné alebo na nič, tmux a vim majú vlastné predstavy o tom, čo vkladanie znamená, a vzdialená relácia cez SSH môže dávku vloženého textu interpretovať spôsobmi, ktoré lokálny počítač nedokáže predvídať. Bracketed paste, copy-mode, insert-mode oproti normal-mode: svet terminálov je plný stavov, kde syntetické vloženie pristane zle alebo nepristane vôbec.

Závisí na tom, že schránka je dostupná a nestrážená. Správcovia schránky ju prepisujú. Správcovia hesiel ju zámerne čistia alebo chránia — bezpečnostná funkcia, ktorá zmení „vlož moje diktovanie“ na „nevlož nič“, potichu. A aj keď všetko funguje, nástroj práve prepísal to, čo ste mali skopírované. SHA commitu, ktorý ste si niesli medzi oknami, je preč a nahradila ho vaša vlastná veta. Pre niekoho, kto žongluje s viacerými dráhami, to nie je škrabnutie; schránka robila svoju prácu.

A závisí — toto je tá časť, ktorá ľudí prekvapuje — na vašom rozložení klávesnice. Keď sa nástroj vráti k simulovaniu stlačení klávesov, naivným spôsobom je posielať kódy klávesov: fyzické pozície klávesov. Kódy klávesov sa mapujú na znaky cez vaše rozloženie. Na QWERTY kód pre „V“ vyprodukuje V. Na Dvoraku je tá istá fyzická pozícia iným písmenom. Nástroj, ktorý simuluje skenkódy na rozložení Dvorak, AZERTY alebo Colemak, teda vyprodukuje text, ktorý vyzerá, akoby prešiel substitučnou šifrou. Používatelia hlásia nezmysly a predpokladajú, že zlyhalo rozpoznávanie reči. Nezlyhalo — reč bola dokonalá, pomotalo ju vkladanie.

Nič z toho nie je z niečej strany zloba ani lenivosť. Vkladanie zo schránky je správne predvolené nastavenie pre 90 % prípadov. Len vývojári trávia deň v tých zvyšných 10 %.

Čo vlastne znamená „napíš to namiesto toho“

Keebye má nastavenie insert_mode s dvomi hodnotami: paste, ktorá je predvolená, a type.

Režim písania nevkladá. Na macOS používa CGEventKeyboardSetUnicodeString — API, ktoré k syntetickej klávesovej udalosti pripojí skutočný text v Unicode. Znak nesie samotná udalosť, nedohľadáva sa cez vaše rozloženie klávesnice. To ho robí nezávislým od rozloženia už z konštrukcie: Dvorak, AZERTY, Colemak, čokoľvek, na čom píšete — text, ktorý dorazí, je ten text, ktorý bol prepísaný, lebo nikdy neexistoval preklad zo skenkódu na znak, ktorý by sa dal pokaziť.

Druhá vlastnosť režimu písania je tá, na ktorej používateľom terminálu záleží: nikdy sa nedotkne schránky. Nula operácií so schránkou na tejto ceste kódu. Obsah vašej schránky zostáva váš — SHA prežije, správca hesiel nemá pred čím strážiť, správca schránky nemá čo logovať.

A pretože terminály a vzdialené relácie sa môžu zahltiť textom prichádzajúcim rýchlejšie, než píše ktorýkoľvek človek, režim písania si zámerne udáva tempo: text ide dnu po 16-znakových blokoch so 4-milisekundovou medzerou medzi blokmi. Dosť rýchlo na to, aby veta pristala hlboko pod jednou sekundou; dosť uvážene na to, aby ju tmux panel cez SSH prijal ako stlačenia klávesov, ktorým stíha, a nie ako blob, ktorý musí interpretovať.

Režim vkladania tu stále je a stále je predvolený, lebo pri veľkých blokoch textu v bežných aplikáciách s grafickým rozhraním je naozaj rýchlejší — trojodsekový slackový odkaz dorazí ako jedno vloženie, nie ako prúd blokov. Aj režim vkladania si však odniesol lekciu o rozloženiach: syntetické Cmd+V používa fyzický kód klávesu V, takže samotné vkladanie sa na non-QWERTY rozloženiach neláme tak, ako sa to stáva prístupom založeným na dohľadávaní znakov.

Praktické nastavenie pre prácu s agentmi je jednoduché: prepnite insert_mode na type, zaostrite terminál, v ktorom beží Claude Code, podržte kláves, vyslovte korekciu, pustite. Prompt dorazí tak, ako by dorazili stlačenia klávesov, lebo pokiaľ ide o terminál, práve tým sú. Krok za krokom je toto nastavenie vrátane špecifík pre SSH a tmux opísané v texte hlasové diktovanie do terminálu macOS.

Úprimné limity

Režim písania je pri dlhom texte pomalší než vkladanie — to je aritmetika, nie chyba. Blokované stlačenia klávesov s medzerami na udanie tempa trvajú dlhšie než jediná udalosť vloženia, a ak diktujete niekoľko odsekov do dokumentu, režim vkladania bude pôsobiť svižnejšie. Presne preto zostáva vkladanie predvolené a režim písania si v nastaveniach zapínate sami; správny režim závisí od toho, kam váš text ide.

Niektoré aplikácie obmedzujú rýchlosť syntetického vstupu alebo ho filtrujú, zvyčajne z bezpečnostných dôvodov, a žiadna stratégia vkladania tomu úplne neunikne — aplikácia, ktorá odmieta syntetické udalosti, ich odmieta od každého nástroja na diktovanie.

A aby bolo jasné, čo tento článok tvrdí a čo nie: sťažnosť na to, že sa vkladanie v termináloch láme, je vzorcom naprieč kategóriou diktovania, nie chybou jedinečnou pre niektorého konkurenta. Iné nástroje majú vlastné odpovede a vlastné silné stránky — napísali sme úprimné porovnania Keebye vs Superwhisper a Keebye vs Wispr Flow vrátane toho, kde vám každý z nich môže sadnúť lepšie.

Vkladanie je neoslnivá polovica diktovania

Rozpoznávanie reči dostáva všetku pozornosť — názvy modelov, tvrdenia o presnosti, počty jazykov. Nástroj na diktovanie má však dve úlohy: počuť vás správne a potom dostať text tam, kde je váš kurzor, bez toho, aby ho stratil alebo pomotal. Druhá úloha znie triviálne a je to miesto, kde kategória potichu zlyháva voči vývojárom, lebo v TextEdite je ľahká a v tmux paneli na vzdialenom stroji pod rozložením Dvorak ťažká.

Ak vaše prompty pristávajú v termináloch — a ak riadite kódovacích agentov, tak pristávajú —, vkladanie nie je poznámka pod čiarou. Je rozdielom medzi nástrojom, ktorý predvádzate, a nástrojom, ktorý používate. Súvisiace spôsoby zlyhania majú mimochodom rovnakú príchuť: prvé slovo diktovania, ktoré zožerie studený štart mikrofónu, je ďalšou sťažnosťou naprieč kategóriou s mechanickým vysvetlením, a spísali sme ju v texte prečo aplikácie na diktovanie zožerú vaše prvé slovo.

Keebye je v predbežnom prístupe pre macOS. Ak sa vám diktovanie niekedy stratilo niekde medzi ústami a terminálom, spustite bezplatnú skúšobnú verziu nižšie, zapnite režim písania a skúste ten istý prompt znova. Skopírovaný SHA zostane v schránke, kým slová dorazia ako napísaný Unicode.