ऐसा डिक्टेशन जो terminal में टिक जाए

डिक्टेशन टूल्स आज़माने वाले developers अक्सर एक बहुत ख़ास शक्ल वाली नाकामी से टकराते हैं। टूल demo में बेहतरीन चलता है। वह Notes में चलता है, Slack में चलता है, browser में चलता है। फिर आप किसी terminal पर focus करते हैं, एक वाक्य डिक्टेट करते हैं, और या तो कुछ नहीं आता, या कुछ ऐसा आता है जो आपने कहा ही नहीं था, या आधा आता है और बाक़ी आधा रहस्यमय तरीक़े से अब आपके clipboard में है। कभी-कभी यह लोकल तो चलता है और जिस पल आप किसी box में SSH करते हैं, दम तोड़ देता है।

यह पैटर्न इतना लगातार दिखता है कि मुझे नहीं लगता यह किसी एक प्रोडक्ट का बग है। यह इस बात का नतीजा है कि यह पूरी category text डालती कैसे है — और वह ठीक उन्हीं जगहों पर नाकाम होती है जहाँ एक developer रहता है।

दो साल पहले के मुक़ाबले आज यह ज़्यादा मायने रखता है। अगर आप Claude Code को आवाज़ से चलाते हैं — वही workflow जो मैंने अपनी आवाज़ से Claude Code चलाना में बताया था — तो terminal कई ऐप्स में से एक नहीं है। वही वह ऐप है। वहीं आपके prompts उतरते हैं, वहीं आपके agents redirects का इंतज़ार करते हैं, वहीं पूरी पैरलल-lane वाली बात या तो चलती है या नहीं चलती। Terminals में लड़खड़ाने वाला डिक्टेशन टूल किसी vibecoder के लिए अपने इकलौते काम में ही लड़खड़ा रहा है।

Paste ठीक वहीं क्यों टूटता है जहाँ developers रहते हैं?

यहाँ category-स्तर की कार्यविधि है। ज़्यादातर डिक्टेशन टूल्स text एक ही तरीक़े से डालते हैं: वे आपके transcribe किए गए वाक्य को सिस्टम clipboard पर रखते हैं, फिर focused ऐप पर एक Cmd+V keystroke बना देते हैं। यह एक समझदार डिफ़ॉल्ट है — paste तात्कालिक है, यह लगभग हर GUI text field में चलता है, और इसके लिए हर ऐप के हिसाब से अलग engineering की लगभग ज़रूरत ही नहीं पड़ी।

समस्या वह सब कुछ है जिस पर यह मान्यता चुपचाप टिकी हुई है।

यह इस पर टिकी है कि focused ऐप Cmd+V को “paste” माने। Terminals अक्सर नहीं मानते — कई Cmd+V को किसी और काम के लिए इस्तेमाल करते हैं या बिलकुल किसी काम के लिए नहीं, tmux और vim के अपने ही विचार हैं कि paste का मतलब क्या है, और कोई remote SSH session paste किए हुए text की बौछार को ऐसे ढंग से समझ सकता है जिसका अंदाज़ा लोकल मशीन नहीं लगा सकती। Bracketed paste, copy-mode, insert-mode बनाम normal-mode: terminal की दुनिया ऐसी स्थितियों से भरी है जहाँ बनावटी paste ग़लत जगह उतरता है या कहीं नहीं उतरता।

यह इस पर टिकी है कि clipboard उपलब्ध और बे-पहरा हो। Clipboard managers उसे दोबारा लिख देते हैं। Password managers जान-बूझकर उसे ख़ाली करते या बचाते हैं — एक सुरक्षा फ़ीचर जो “मेरा डिक्टेशन paste करो” को चुपचाप “कुछ भी paste मत करो” में बदल देता है। और जब सब कुछ चल भी जाए, तब भी टूल ने वह मिटा दिया जो आपने कॉपी कर रखा था। जो commit SHA आप windows के बीच लिए घूम रहे थे, वह ग़ायब है, उसकी जगह आपका अपना वाक्य है। कई lanes सँभाल रहे किसी इंसान के लिए यह मामूली खरोंच नहीं है; clipboard एक काम कर रहा था।

और यह इस पर भी टिकी है — यही वह बात है जो लोगों को चौंकाती है — कि आपका keyboard layout क्या है। जब कोई टूल keystrokes की नक़ल करने पर लौटता है, तो भोला तरीक़ा यह है कि key codes भेजे जाएँ: यानी keys की भौतिक जगहें। Key codes आपके layout के ज़रिए characters से जुड़ते हैं। QWERTY पर “V” का code एक V बनाता है। Dvorak पर वही भौतिक जगह एक अलग अक्षर है। इसलिए जो टूल Dvorak, AZERTY या Colemak layout पर scancodes की नक़ल करता है, वह ऐसा text बनाता है जो देखने में किसी substitution cipher से गुज़रा लगता है। Users बकवास text की शिकायत करते हैं और मान लेते हैं कि speech recognition नाकाम रही। वह नाकाम नहीं हुई थी — speech बिलकुल ठीक थी, insertion ने उसे उलझा दिया।

इसमें किसी की बदनीयती या आलस नहीं है। 90% मामलों के लिए clipboard-paste सही डिफ़ॉल्ट है। बात बस यह है कि developers अपना दिन बाक़ी 10% में बिताते हैं।

“इसके बजाय टाइप कर दो” का असल मतलब क्या है

Keebye में insert_mode नाम की एक setting है जिसके दो मान हैं: paste, जो डिफ़ॉल्ट है, और type।

Type mode paste नहीं करता। macOS पर यह CGEventKeyboardSetUnicodeString इस्तेमाल करता है — एक ऐसी API जो असली Unicode text को एक बनावटी key event के साथ जोड़ देती है। अक्षर event के भीतर ही ढोया जाता है, आपके keyboard layout से देखकर निकाला नहीं जाता। इससे यह बनावट से ही layout-निरपेक्ष हो जाता है: Dvorak, AZERTY, Colemak, आप जिस पर भी टाइप करें, जो text पहुँचता है वही text transcribe हुआ था, क्योंकि scancode-से-अक्षर वाला अनुवाद कभी था ही नहीं कि ग़लत हो जाता।

Type mode की दूसरी ख़ूबी वही है जिसकी terminal users को परवाह है: यह clipboard को छूता तक नहीं। उस code path पर clipboard की गतिविधि शून्य है। आपके clipboard की सामग्री आपकी ही रहती है — SHA बचा रहता है, password manager के पास बचाने को कुछ नहीं, clipboard manager के पास लिखने को कुछ नहीं।

और चूँकि terminals तथा remote sessions ऐसे text पर अटक सकते हैं जो किसी भी इंसान की टाइपिंग से तेज़ आए, इसलिए type mode जान-बूझकर अपनी रफ़्तार सँभालता है: text 16-अक्षर के chunks में जाता है, हर chunk के बीच 4 मिलीसेकंड का अंतराल। इतना तेज़ कि एक वाक्य एक सेकंड से भी काफ़ी कम में उतर जाए; इतना नपा-तुला कि SSH पर चल रहा कोई tmux pane उसे ऐसे keystrokes की तरह पाए जिनके साथ वह चल सके, न कि ऐसे थक्के की तरह जिसे उसे समझना पड़े।

Paste mode अब भी मौजूद है, और अब भी डिफ़ॉल्ट है, क्योंकि सामान्य GUI ऐप्स में text के बड़े हिस्सों के लिए वह सचमुच तेज़ है — तीन पैराग्राफ़ का Slack मैसेज chunks की धार के बजाय एक ही paste में पहुँचता है। हालाँकि layout वाला सबक़ paste mode ने भी सीखा: बनावटी Cmd+V भौतिक V keycode इस्तेमाल करता है, इसलिए non-QWERTY layouts पर paste ख़ुद वैसे नहीं टूटता जैसे अक्षर-आधारित तरीक़े टूट सकते हैं।

Agent वाले काम के लिए व्यावहारिक setup सीधा है: insert_mode को type कर दें, Claude Code चला रहे terminal पर focus करें, key दबाए रखें, redirect बोलें, छोड़ दें। Prompt वैसे ही पहुँचता है जैसे keystrokes पहुँचते, क्योंकि terminal जहाँ तक बता सकता है, वे keystrokes ही हैं। इस setup का क़दम-दर-क़दम रूप, SSH और tmux की तफ़सील समेत, macOS terminal के लिए वॉइस डिक्टेशन में है।

ईमानदार सीमाएँ

लंबे text के लिए type mode paste से धीमा है — यह गणित है, कोई ख़राबी नहीं। रफ़्तार सँभालने वाले अंतरालों के साथ chunked keystrokes एक अकेले paste event से ज़्यादा समय लेते हैं, और अगर आप किसी document में कई पैराग्राफ़ डिक्टेट कर रहे हैं तो paste mode ज़्यादा चुस्त लगेगा। ठीक इसीलिए paste डिफ़ॉल्ट बना रहता है और type mode वह चीज़ है जिसे आप settings में जान-बूझकर चुनते हैं; सही mode इस पर निर्भर करता है कि आपका text जा कहाँ रहा है।

कुछ applications बनावटी इनपुट की रफ़्तार सीमित कर देते हैं या उसे छानते हैं, आम तौर पर सुरक्षा के कारणों से, और कोई भी insertion रणनीति उससे पूरी तरह नहीं बच पाती — जो ऐप बनावटी events मना करता है, वह उन्हें हर डिक्टेशन टूल से मना करता है।

और यह साफ़ कर देना ज़रूरी है कि यह लेख क्या दावा कर रहा है और क्या नहीं: “terminals में paste टूट जाता है” वाली शिकायत पूरी डिक्टेशन category में फैला एक पैटर्न है, किसी एक प्रतिद्वंद्वी की अनोखी ख़राबी नहीं। दूसरे टूल्स के अपने जवाब और अपनी ख़ूबियाँ हैं — हमने Keebye vs Superwhisper और Keebye vs Wispr Flow पर ईमानदार तुलनाएँ लिखी हैं, जिनमें यह भी है कि इनमें से कौन आप पर बेहतर बैठ सकता है।

Insertion डिक्टेशन का बे-चमक वाला आधा हिस्सा है

सारा ध्यान speech recognition को मिलता है — मॉडलों के नाम, सटीकता के दावे, भाषाओं की गिनती। पर किसी डिक्टेशन टूल के दो काम हैं: आपको सही सुनना, और फिर text को वहाँ पहुँचाना जहाँ आपका cursor है, बिना उसे खोए या बिगाड़े। दूसरा काम सुनने में मामूली लगता है और वहीं यह category चुपचाप developers को धोखा देती है, क्योंकि दूसरा काम TextEdit में आसान है और Dvorak layout के नीचे किसी remote box पर चल रहे tmux pane में मुश्किल।

अगर आपके prompts terminals में उतरते हैं — और अगर आप coding agents चला रहे हैं तो वे वहीं उतरते हैं — तो insertion कोई footnote नहीं है। यही वह फ़र्क़ है जो demo किए जाने वाले टूल और इस्तेमाल किए जाने वाले टूल के बीच होता है। वैसे, इससे मिलती-जुलती नाकामियों का स्वाद भी वही है: mic के ठंडे स्टार्ट की वजह से डिक्टेशन का पहला शब्द खा लिया जाना एक और category-भर की शिकायत है जिसकी यांत्रिक व्याख्या मौजूद है, और उस पर हमने डिक्टेशन ऐप्स आपका पहला शब्द क्यों खा जाते हैं में लिखा है।

Keebye macOS के लिए अर्ली ऐक्सेस में है। अगर आपका डिक्टेशन कभी आपके मुँह और किसी terminal के बीच कहीं ग़ायब हुआ है, तो नीचे अपना फ़्री ट्रायल शुरू करें, type mode चालू करें, और वही prompt दोबारा आज़माएँ। आपका कॉपी किया हुआ SHA clipboard पर बना रहता है जबकि शब्द टाइप किए हुए Unicode की तरह पहुँचते हैं।