Dyktowanie, które przetrwa terminal

Programiści, którzy próbują narzędzi do dyktowania, często trafiają na awarię o bardzo konkretnym kształcie. Narzędzie działa pięknie w demie. Działa w Notatkach, na Slacku, w przeglądarce. Potem ustawiasz fokus na terminalu, dyktujesz zdanie i albo nic się nie pojawia, albo pojawia się coś, czego nie powiedziałeś, albo pojawia się połowa, a druga połowa jest teraz w tajemniczy sposób w Twoim schowku. Czasem działa lokalnie i umiera w chwili, gdy wchodzisz przez SSH na jakąś maszynę.

Wzorzec jest na tyle powtarzalny, że nie sądzę, by to był błąd w jednym konkretnym produkcie. To konsekwencja tego, jak cała kategoria wstawia tekst — i zawodzi dokładnie w tych miejscach, w których żyje programista.

Dziś ma to większe znaczenie niż dwa lata temu. Jeśli sterujesz Claude Code głosem — praca, którą opisałem w Sterowanie Claude Code głosem — to terminal nie jest jedną z wielu aplikacji. Jest tą aplikacją. Tam lądują Twoje prompty, tam Twoi agenci czekają na korekty kursu, tam cała ta rzecz z równoległymi torami albo działa, albo nie. Narzędzie do dyktowania, które jest kapryśne w terminalach, jest dla vibe codera kapryśne w swojej jedynej pracy.

Dlaczego wklejanie psuje się dokładnie tam, gdzie żyją programiści?

Oto mechanika na poziomie kategorii. Większość narzędzi do dyktowania wstawia tekst tak samo: umieszcza przetranskrybowane zdanie w schowku systemowym, a potem generuje syntetyczne Cmd+V w aktywnej aplikacji. To sensowny domyślny wybór — wklejanie jest natychmiastowe, działa w prawie każdym polu tekstowym GUI i prawie nie wymagało inżynierii pod poszczególne aplikacje.

Problem tkwi we wszystkim, od czego to założenie po cichu zależy.

Zależy od tego, czy aktywna aplikacja traktuje Cmd+V jako „wklej”. Terminale często tego nie robią — wiele używa Cmd+V do czegoś innego albo do niczego, tmux i vim mają własne pomysły na to, czym jest wklejanie, a zdalna sesja SSH może zinterpretować lawinę wklejonego tekstu w sposób, którego lokalna maszyna nie przewidzi. Bracketed paste, copy-mode, tryb wstawiania kontra tryb normalny: świat terminali jest pełen stanów, w których syntetyczne wklejenie ląduje źle albo nie ląduje wcale.

Zależy od tego, czy schowek jest dostępny i niepilnowany. Menedżery schowka go nadpisują. Menedżery haseł celowo go czyszczą albo chronią — funkcja bezpieczeństwa, która zamienia „wklej moje dyktowanie” w „wklej nic”, po cichu. A nawet kiedy wszystko działa, narzędzie właśnie nadpisało to, co miałeś skopiowane. SHA commita, który przenosiłeś między oknami, zniknął, zastąpiony Twoim własnym zdaniem. Dla kogoś żonglującego kilkoma torami to nie jest drobne zadraśnięcie; schowek wykonywał zadanie.

I zależy — to jest ten punkt, który ludzi zaskakuje — od Twojego układu klawiatury. Kiedy narzędzie przechodzi na symulowanie naciśnięć klawiszy, naiwny sposób to wysyłanie kodów klawiszy: fizycznych pozycji. Kody klawiszy mapują się na znaki przez Twój układ. Na QWERTY kod dla „V” daje V. Na Dvoraku ta sama fizyczna pozycja to inna litera. Narzędzie symulujące scancode'y na układzie Dvorak, AZERTY albo Colemak produkuje więc tekst wyglądający, jakby przeszedł przez szyfr podstawieniowy. Użytkownicy zgłaszają bełkot i zakładają, że zawiodło rozpoznawanie mowy. Nie zawiodło — mowa była idealna, to wstawianie ją przemieszało.

Nic z tego nie wynika ze złej woli ani z lenistwa. Wklejanie ze schowka jest właściwym domyślnym wyborem w 90% przypadków. Rzecz w tym, że programiści spędzają dzień w pozostałych 10%.

Co naprawdę znaczy „wpisz to zamiast wklejać”

Keebye ma ustawienie o nazwie insert_mode z dwiema wartościami: paste, czyli domyślną, oraz type.

Tryb wpisywania nie wkleja. Na macOS używa CGEventKeyboardSetUnicodeString — API, które dołącza faktyczny tekst Unicode do syntetycznego zdarzenia klawiatury. Znak jest niesiony w samym zdarzeniu, a nie wyszukiwany przez Twój układ klawiatury. To czyni go niezależnym od układu z konstrukcji: Dvorak, AZERTY, Colemak, cokolwiek, na czym piszesz — dociera dokładnie ten tekst, który został przetranskrybowany, bo nigdy nie było translacji ze scancode'u na znak, która mogłaby pójść źle.

Druga własność trybu wpisywania to ta, na której zależy użytkownikom terminala: nigdy nie dotyka schowka. Zero operacji na schowku w tej ścieżce kodu. Zawartość schowka zostaje Twoja — SHA przeżywa, menedżer haseł nie ma się przed czym bronić, menedżer schowka nie ma czego logować.

A ponieważ terminale i zdalne sesje potrafią się zakrztusić tekstem przychodzącym szybciej, niż pisze jakikolwiek człowiek, tryb wpisywania celowo się miarkuje: tekst wchodzi w porcjach po 16 znaków z 4-milisekundową przerwą między porcjami. Wystarczająco szybko, by zdanie wylądowało w wyraźnie mniej niż sekundę; wystarczająco wyważenie, by panel tmuxa przez SSH odebrał je jako naciśnięcia klawiszy, za którymi nadąża, a nie jako blob do zinterpretowania.

Tryb wklejania nadal tam jest i nadal jest domyślny, bo przy dużych blokach tekstu w zwykłych aplikacjach GUI jest naprawdę szybszy — trzyakapitowa wiadomość na Slacku dociera jako jedno wklejenie, a nie strumień porcji. Nawet tryb wklejania odrobił jednak lekcję o układach: syntetyczne Cmd+V używa fizycznego kodu klawisza V, więc samo wklejanie nie psuje się na układach innych niż QWERTY tak, jak potrafią to podejścia oparte na wyszukiwaniu znaków.

Praktyczna konfiguracja do pracy z agentami jest prosta: przestaw insert_mode na type, ustaw fokus na terminalu z Claude Code, przytrzymaj klawisz, powiedz korektę kursu, puść. Prompt dociera tak, jakby przyszedł z klawiatury, bo z punktu widzenia terminala właśnie stamtąd przyszedł. Wersja krok po kroku tej konfiguracji, razem ze specyfiką SSH i tmuxa, jest w Głosowe dyktowanie do terminala na macOS.

Szczere granice

Tryb wpisywania jest przy długim tekście wolniejszy niż wklejanie — to arytmetyka, nie wada. Porcjowane naciśnięcia klawiszy z przerwami trwają dłużej niż jedno zdarzenie wklejenia, a jeśli dyktujesz kilka akapitów do dokumentu, tryb wklejania będzie wydawał się żwawszy. Dokładnie dlatego wklejanie pozostaje domyślne, a tryb wpisywania włączasz sam w ustawieniach; właściwy tryb zależy od tego, dokąd zmierza Twój tekst.

Niektóre aplikacje ograniczają albo filtrują syntetyczne wejście, zwykle ze względów bezpieczeństwa, i żadna strategia wstawiania w pełni tego nie omija — aplikacja, która odrzuca syntetyczne zdarzenia, odrzuca je z każdego narzędzia do dyktowania.

I żeby jasno powiedzieć, co ten artykuł twierdzi, a czego nie: skarga „wklejanie psuje się w terminalach” to wzorzec w całej kategorii dyktowania, a nie wada charakterystyczna dla któregoś konkurenta. Inne narzędzia mają własne odpowiedzi i własne mocne strony — napisaliśmy uczciwe porównania w Keebye vs Superwhisper i Keebye vs Wispr Flow, łącznie z tym, gdzie każde z nich może pasować Ci lepiej.

Wstawianie to niewdzięczna połowa dyktowania

Rozpoznawanie mowy zbiera całą uwagę — nazwy modeli, deklaracje dokładności, liczby języków. Ale narzędzie do dyktowania ma dwa zadania: usłyszeć Cię poprawnie, a potem dostarczyć tekst tam, gdzie jest Twój kursor, nie gubiąc go ani nie kalecząc. Drugie zadanie brzmi trywialnie i to na nim kategoria po cichu zawodzi programistów, bo jest łatwe w TextEdit, a trudne w panelu tmuxa na zdalnej maszynie pod układem Dvorak.

Jeśli Twoje prompty lądują w terminalach — a jeśli sterujesz agentami kodującymi, to lądują — wstawianie nie jest przypisem. To różnica między narzędziem, które pokazujesz, a narzędziem, którego używasz. Pokrewne tryby awarii mają zresztą ten sam smak: zjadanie pierwszego słowa dyktowania przez zimny start mikrofonu to kolejna skarga na całą kategorię z mechanicznym wyjaśnieniem, którą opisaliśmy w Dlaczego aplikacje do dyktowania zjadają Twoje pierwsze słowo.

Keebye jest we wczesnym dostępie na macOS. Jeśli Twoje dyktowanie kiedykolwiek zniknęło gdzieś między ustami a terminalem, zacznij bezpłatny okres próbny poniżej, włącz tryb wpisywania i powtórz ten sam prompt. Skopiowany SHA zostaje w schowku, a słowa docierają jako wpisany Unicode.