Terminalde Ayakta Kalan Dikte

Dikte yapıştırma terminal, SSH, tmux ve QWERTY olmayan düzenlerde sessizce aksar. Pano girişi neden bozulur, yazma modu yerine ne yapar?

Teodor Deleanu10 Temmuz 20266 dk okuma

Dikte araçlarını deneyen geliştiriciler sık sık çok belirli bir biçimi olan bir hatayla karşılaşıyor. Araç demoda kusursuz çalışıyor. Notlar'da, Slack'te, tarayıcıda çalışıyor. Sonra bir terminale odaklanıp bir cümle dikte ediyorsun ve ya hiçbir şey belirmiyor, ya söylediğin olmayan bir şey beliriyor, ya da yarısı beliriyor ve öteki yarısı gizemli biçimde panonda oluyor. Bazen yerelde çalışıyor ve bir makineye SSH ile bağlandığın anda ölüyor.

Bu örüntü, tek bir üründeki bir hata olduğunu düşünmeyeceğim kadar tutarlı. Kategorinin metni nasıl girdiğinin bir sonucu — ve tam olarak bir geliştiricinin yaşadığı yerlerde başarısız oluyor.

Bu, iki yıl öncesine göre çok daha önemli. Claude Code'u sesinle yönetiyorsan — Claude Code'u sesinle yönetmek yazısında anlattığım iş akışı — terminal, pek çok uygulamadan biri değil. O, tek uygulama. Prompt'larının düştüğü yer, agent'larının yön beklediği yer, tüm o paralel lane işinin ya yürüdüğü ya da yürümediği yer. Terminallerde kararsız çalışan bir dikte aracı, bir vibe-coder için tek işinde kararsız demek.

Yapıştırma tam da geliştiricilerin yaşadığı yerde neden bozuluyor?

Kategori düzeyindeki mekanik şu. Çoğu dikte aracı metni aynı yolla giriyor: transkribe ettiğin cümleyi sistem panosuna koyuyor, sonra odaktaki uygulamada bir Cmd+V tuş vuruşu sentezliyor. Mantıklı bir varsayılan — yapıştırma anlık, neredeyse her GUI metin alanında çalışıyor ve uygulama başına neredeyse hiç mühendislik gerektirmedi.

Sorun, bu varsayımın sessizce dayandığı her şey.

Odaktaki uygulamanın Cmd+V'yi "yapıştır" olarak ele almasına dayanıyor. Terminaller çoğu zaman öyle yapmıyor — pek çoğu Cmd+V'yi başka bir şey için ya da hiçbir şey için kullanıyor, tmux ve vim'in yapıştırmanın ne demek olduğuna dair kendi fikirleri var ve uzak bir SSH oturumu, yapıştırılmış metin salvosunu yerel makinenin öngöremeyeceği şekillerde yorumlayabiliyor. Bracketed paste, copy-mode, insert-mode ile normal-mode karşılaştırması: terminal dünyası, sentetik bir yapıştırmanın yanlış yere ya da hiçbir yere düştüğü durumlarla dolu.

Panonun kullanılabilir ve korumasız olmasına dayanıyor. Pano yöneticileri onu yeniden yazıyor. Parola yöneticileri onu kasten temizliyor ya da koruyor — "dikteyi yapıştır"ı sessizce "hiçbir şey yapıştırma"ya çeviren bir güvenlik özelliği. Ve her şey çalıştığında bile araç, kopyalamış olduğun neyse onun üzerine yazmış oluyor. Pencereler arasında taşıdığın commit SHA'sı gitti, yerini senin cümlen aldı. Birkaç lane'i aynı anda çeviren biri için bu bir çizik değil; panonun bir işi vardı.

Ve — insanları şaşırtan kısım bu — klavye düzenine dayanıyor. Bir araç tuş vuruşlarını taklit etmeye geri düştüğünde naif yol tuş kodları göndermek: fiziksel tuş konumları. Tuş kodları karakterlere senin düzeninden geçerek eşleniyor. QWERTY'de "V" kodu bir V üretiyor. Dvorak'ta aynı fiziksel konum başka bir harf. Yani Dvorak, AZERTY ya da Colemak düzeninde scancode taklit eden bir araç, yerine koyma şifresinden geçmiş gibi görünen bir metin üretiyor. Kullanıcılar anlamsız çıktı bildiriyor ve konuşma tanımanın başarısız olduğunu varsayıyor. Öyle olmadı — konuşma kusursuzdu, metin girişi onu karıştırdı.

Bunların hiçbiri kimsenin kötü niyeti ya da tembelliği değil. Pano-yapıştırma, %90'lık durum için doğru varsayılan. Sadece geliştiriciler gününü kalan %10'da geçiriyor.

"Onun yerine yaz" gerçekte ne demek

Keebye'ın insert_mode adında, iki değeri olan bir ayarı var: varsayılan olan paste ve type.

Yazma modu yapıştırmıyor. macOS'ta CGEventKeyboardSetUnicodeString kullanıyor — gerçek Unicode metni sentetik bir tuş olayına iliştiren bir API. Karakter, klavye düzeninden aranarak değil, olayın kendisinde taşınıyor. Bu da onu yapısı gereği düzenden bağımsız kılıyor: Dvorak, AZERTY, Colemak, ne kullanıyorsan kullan, ulaşan metin transkribe edilen metin oluyor, çünkü yanlış gidecek bir scancode-karakter çevirisi hiç olmadı.

Yazma modunun ikinci özelliği, terminal kullanıcılarının önemsediği özellik: panoya asla dokunmuyor. O kod yolunda sıfır pano işlemi. Pano içeriğin senin kalıyor — SHA hayatta kalıyor, parola yöneticisinin karşı koruyacağı bir şey olmuyor, pano yöneticisinin kaydedeceği bir şey olmuyor.

Ve terminaller ile uzak oturumlar, hiçbir insanın yazamayacağı hızda gelen metinde tıkanabildiği için yazma modu kendini bilerek yavaşlatıyor: metin 16 karakterlik parçalar hâlinde, parçalar arasında 4 milisaniyelik boşlukla giriyor. Bir cümlenin bir saniyenin epey altında düşeceği kadar hızlı; SSH üzerindeki bir tmux panelinin, yorumlaması gereken bir yığın olarak değil, yetişebileceği tuş vuruşları olarak alacağı kadar ölçülü.

Yapıştırma modu hâlâ orada ve hâlâ varsayılan, çünkü normal GUI uygulamalarındaki büyük metin blokları için gerçekten daha hızlı — üç paragraflık bir Slack mesajı, parça akışı yerine tek bir yapıştırma olarak varıyor. Yine de yapıştırma modu da düzen dersini aldı: sentetik Cmd+V, fiziksel V tuş kodunu kullanıyor, yani yapıştırmanın kendisi QWERTY olmayan düzenlerde karakter arama yaklaşımlarının bozulduğu gibi bozulmuyor.

Agent işi için pratik kurulum basit: insert_mode'u type'a çevir, Claude Code çalıştıran terminale odaklan, tuşu basılı tut, yön değişikliğini söyle, bırak. Prompt tuş vuruşlarının varacağı gibi varıyor, çünkü terminalin anladığı kadarıyla onlar zaten tuş vuruşu. Bu kurulumun SSH ve tmux ayrıntıları dahil adım adım bir sürümü macOS terminali için sesli dikte sayfasında.

Dürüst sınırlar

Yazma modu uzun metin için yapıştırmadan yavaş — bu bir kusur değil, aritmetik. Aralarında boşluk olan parçalı tuş vuruşları tek bir yapıştırma olayından uzun sürüyor ve bir belgeye birkaç paragraf dikte ediyorsan yapıştırma modu daha çevik hissettirecek. Yapıştırmanın varsayılan kalmasının ve yazma modunun ayarlardan bilerek açtığın bir şey olmasının nedeni tam olarak bu; doğru mod, metnin nereye gittiğine bağlı.

Bazı uygulamalar sentetik girişi genellikle güvenlik nedeniyle hız sınırlıyor ya da filtreliyor ve hiçbir metin girişi stratejisi bundan tamamen kaçamıyor — sentetik olayları reddeden bir uygulama onları her dikte aracından reddediyor.

Ve bu yazının ne iddia edip ne iddia etmediği konusunda açık olalım: yapıştırma-terminallerde-bozuluyor şikâyeti dikte kategorisi genelinde bir örüntü, herhangi bir rakibe özgü bir kusur değil. Diğer araçların kendi yanıtları ve kendi güçlü yanları var — her birinin sana nerede daha iyi uyabileceği dahil, dürüst karşılaştırmaları Keebye vs Superwhisper ve Keebye vs Wispr Flow sayfalarında yazdık.

Metin girişi, diktenin gösterişsiz yarısı

Bütün ilgiyi konuşma tanıma topluyor — model adları, isabet iddiaları, dil sayıları. Ama bir dikte aracının iki işi var: seni doğru duymak ve sonra metni, kaybetmeden ya da bozmadan imlecinin olduğu yere ulaştırmak. İkinci iş kulağa önemsiz geliyor ve kategorinin geliştiricileri sessizce yüzüstü bıraktığı yer orası, çünkü ikinci iş TextEdit'te kolay, Dvorak düzenli uzak bir makinedeki tmux panelinde zor.

Prompt'ların terminallere düşüyorsa — ve kodlama agent'ları yönetiyorsan düşüyor — metin girişi bir dipnot değil. Demo ettiğin araçla kullandığın araç arasındaki fark. Bu arada ilgili hata biçimlerinin tadı aynı: mikrofonun soğuk başlangıcı yüzünden diktenin ilk kelimesinin yutulması da kategori genelinde, mekanik açıklaması olan bir başka şikâyet; onu da dikte uygulamaları ilk kelimeni neden yutuyor yazısında ele aldık.

Keebye macOS için erken erişimde. Dikten hiç ağzınla bir terminal arasında bir yerde kaybolduysa ücretsiz denemeni aşağıdan başlat, yazma modunu aç ve aynı prompt'u tekrar dene. Kopyaladığın SHA panoda kalırken kelimeler yazılmış Unicode olarak varır.

En zorlu terminal yolunu test et

Ücretsiz denemeni başlat, yazma modunu aç ve yapıştırmayı genellikle bozan SSH ya da tmux prompt'unu dene.

Start free trial

Early access: we'll email you the moment the macOS build is ready — your 14 days start when you first sign in from the app.

Okumaya devam et