मैंने अपना खुद का टेक्स्ट एडिटर बनाया है, और हर दिन उसका इस्तेमाल करता हूँ

 (blog.jsbarretto.com)
8 पॉइंट द्वारा GN⁺ 2026-03-12 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा Howl एडिटर की सीमाओं (डेवलपमेंट बंद, धीमी search, SSH incompatibility, terminal support की कमी) के कारण लेखक ने खुद एक नया TUI टेक्स्ट एडिटर बनाया
  • Helix, VS Code, Vim, Neovim, Emacs सहित 13 एडिटर आज़माने के बाद भी ऐसा कोई एडिटर नहीं मिला जो मनचाहा ऑपरेशन फील (Fingerspitzengefühl) दे सके
  • शुरुआत में केवल व्यक्तिगत रूप से ज़रूरी न्यूनतम फीचर लागू किए गए, और performance, Unicode, multilingual support जैसी चीज़ों को बाद के लिए टालते हुए धीरे-धीरे विस्तार किया गया
  • डेवलपमेंट के दौरान अपना regex engine, file browser, TUI-based rendering, terminal buffer integration आदि सीधे खुद लागू किए गए
  • project-wide search, syntax highlighting, cache handling, multi-threaded work distribution आदि में performance optimization techniques व्यापक रूप से लागू की गईं
  • नतीजतन, लेखक ने बताया कि उसने ऐसा टूल पूरा किया जो उसके अपने workflow पर पूरी तरह फिट बैठता है, और इससे productivity और programming का आनंद फिर से मिल गया

मौजूदा एडिटर की सीमाएँ और विकल्पों की तलाश

  • लगभग 10 साल तक इस्तेमाल किए गए Howl एडिटर की समस्याएँ ही खुद एडिटर बनाने की वजह बनीं
    • कई सालों से डेवलपमेंट रुका हुआ था, इसलिए लेखक खुद उसका fork बनाए हुए था, लेकिन वह MoonScript में लिखा होने के कारण गहराई से बदलाव करना मुश्किल था
    • पूरे project में file search performance कमजोर होने से workflow बार-बार टूटता था
    • यह एक GUI एडिटर था, इसलिए SSH connection के जरिए remote use संभव नहीं था
    • integrated terminal न होने से external commands चलाते समय live interaction संभव नहीं था, और ज़्यादातर ANSI escape codes भी unsupported थे
  • Helix, VS Code, Sublime Text, Vim, Zed, Neovim, Emacs, Geany, Micro, Lite XL, Lapce, GNOME Builder, Kakoune सहित 13 एडिटर आज़माए गए
    • हर एक की अपनी खूबियाँ थीं, लेकिन कोई भी मनचाहा ऑपरेशन फील (Fingerspitzengefühl) नहीं दे पाया
    • Helix का सबसे लंबे समय तक इस्तेमाल किया गया, लेकिन एक महीने बाद उसमें भी रुचि खत्म हो गई

शुरुआती डेवलपमेंट रणनीति

  • शुरुआत में scope को न्यूनतम रखा गया
    • लेखक के अलावा किसी और user के लिए फीचर नहीं जोड़े गए, और सारी settings hardcode की गईं
    • performance optimization को टालकर String-based buffer से शुरुआत की गई
    • Unicode grapheme के पूर्ण support को छोड़ा गया; यह मान लिया गया कि £ चिन्ह अगर एक single column लेता है तो वही काफी है
    • syntax highlighting सिर्फ उन कुछ languages के लिए दी गई जो अक्सर इस्तेमाल होती थीं, बाकी के लिए generic delimiter-based highlighting इस्तेमाल की गई
  • दूसरी कोशिश में पहले एक साधारण TUI framework बनाया गया, लेकिन समय के साथ उसका अधिकांश हिस्सा हटाकर अधिक सीधा और सूक्ष्म तरीका अपनाया गया

Dogfooding का अभ्यास

  • जब एडिटर इतना सक्षम हो गया कि वह एक single file खोल, edit और save कर सके, तब तीन अभ्यास शुरू किए गए
    • nano की जगह system files edit करने या notes लिखने में अपने ही एडिटर का जबरन इस्तेमाल
    • कोई missing feature, bug, अजीब behavior या limitation दिखते ही project के README.md में दर्ज करना
    • जो समस्याएँ बहुत irritate करें, उन्हें तुरंत ठीक करना
  • इन तीन आदतों से काम का समय महीने के 1 घंटे से बढ़कर हर हफ्ते कई घंटे हो गया
  • कुल लगभग 10,000 lines code में से लगभग ज़्यादातर पिछले 6 महीनों में लिखी गईं

कर्सर नियंत्रण

  • cursor manipulation लागू करने में कठिन क्षेत्र है
    • ctrl + shift + left जैसे key combinations users को सहज लगते हैं, लेकिन उनका logic लागू करना जटिल होता है
  • मुख्य सलाह यह है कि high-level input को primitive operations के संयोजन के रूप में लागू किया जाए
    • उदाहरण: word-wise backspace → word-wise cursor move + range select + delete में तोड़ना
  • undo/redo लागू करते समय इन 3 क्रियाओं को एक group में बाँधना चाहिए ताकि परिणाम सहज लगे
  • इससे समझ आता है कि modal editors ऐसे primitive operations सीधे user को expose क्यों करते हैं

फ़ाइल ब्राउज़र

  • Howl का file browser वह निर्णायक कारण था जिसकी वजह से लेखक दूसरे एडिटर पर नहीं जा पा रहा था
    • उसका तुरंत अपडेट होने वाला fuzzy filter इतना अच्छा था कि अक्सर 1–2 key presses में मनचाही file मिल जाती थी
    • अगर file मौजूद न हो, तो उसे inline create किया जा सकता था
    • ~/ टाइप करने पर home directory में अपने-आप switch हो जाता था
    • main editing pane में खोली जाने वाली file का preview दिखता था
  • दूसरे एडिटरों द्वारा file open समस्या को mouse dependency, GTK default dialog, filename guessing जैसे तरीकों से हल करने पर असंतोष जताया गया
  • खुद लागू करने पर Levenshtein distance जैसी जटिल तकनीकों की बजाय 3 सरल मानदंड काफी निकले
    • क्या path filter phrase से शुरू होता है
    • क्या path उसमें phrase को शामिल करता है
    • सबसे हाल का modification/access time
  • case-insensitive matching की अनुमति दी गई, लेकिन case match होने पर रैंक थोड़ा ऊपर किया गया
  • दसियों हज़ार files वाले project में भी 2 key presses के बाद लगभग 95% संभावना रहती थी कि मनचाही file top 2 results में हो

regex engine

  • regex का उपयोग project-wide search, syntax highlighting, buffer के अंदर find—इन तीन जगहों पर होता है
  • मौजूदा regex-automata crate की जगह खुद implementation करने के कारण
    • Rust raw string syntax जैसे context-sensitive edge cases संभालने की ज़रूरत
    • और यह project अपना stack बनाने और समझने का अभ्यास भी था
  • शुरुआती implementation में parsing crate chumsky से regex syntax parse किया गया और हर character पर AST traverse किया जाता था, जो बहुत धीमा था
  • बाद में चरणबद्ध optimization किए गए
    • single-pass optimizer: बार-बार आने वाले character matching groups को एक String node में बदलकर exact string search करना
    • common prefix extraction: जैसे hel[(lo)p] में common prefix hel निकालकर केवल उस position पर matching करना → project-wide search में बड़ा performance gain
    • AST walker को Rust dynamic dispatch आधारित threaded code VM के रूप में दोबारा लागू करना
    • threaded code VM को CPS (Continuation-Passing Style) में बदलना, ताकि हर VM instruction अगली instruction को tail-call करे और compiler optimization का लाभ मिले
    • Rust की धीमी dynamic function calls को vtable lookup के बिना wrap करना, जिससे कई regex instructions का codegen कुछ machine instructions तक सिमट गया
    • जितना संभव हो, regex instructions को Unicode codepoints की बजाय byte-level पर लागू करना; UTF-8 design के कारण ASCII optimization multi-byte codepoints पर भी कारगर रही
  • jump LUT chain में compile करने की भी कोशिश की गई, लेकिन benchmark में threaded code की तुलना में सिर्फ 20–30% तेज़ी मिली और flexibility बहुत घट गई, इसलिए उसे नहीं अपनाया गया
  • अंतिम परिणाम: Rust के लिए सबसे जटिल syntax highlighting में भी 50,000-line auto-generated binding file को clean state से 10 milliseconds से कम में पूरी तरह highlight किया जा सका

syntax highlighting cache

  • शुरुआत में हर बदलाव पर पूरी file को फिर से highlight किया जाता था, लेकिन बड़ी files में performance गिरती थी
  • इसके लिए on-demand token highlighting cache लागू किया गया
    • tokens को लगभग समान आकार के chunks में highlight किया गया
    • buffer में damage होने पर केवल उस स्थान से overlap करने वाले या उसके बाद वाले chunks को invalidate किया गया
  • सबसे pessimistic case (बड़ी file के बीच में edit) में भी damage से पहले का highlight state बना रहता है, और screen के नीचे का हिस्सा highlight info मांगा ही नहीं जाता, इसलिए उसे process करने की ज़रूरत नहीं पड़ती
  • यह demand-driven approach होने के कारण, उसी buffer के अलग-अलग हिस्से देखने वाले multiple panels में भी सही काम करती है

project-wide search

  • search process के 4 चरण
    • current directory से उलटी दिशा में .git/ directory खोजकर project root तय करना
    • project root की सभी directories को recursively traverse करके search pattern को file contents से match करना
    • हर positive match पर file snippet निकालना और result preview के लिए syntax highlighting लागू करना
    • current path से navigation distance के आधार पर results को rank करना (करीबी files को ऊँची rank)
  • build directories आदि से बचने के लिए default filtering rules लागू की गईं
  • multi-threaded processing के लिए basic work-stealing शैली में threads के बीच काम बाँटा गया
    • ऐसी विशेष संरचना में, जहाँ सभी threads producer भी हैं और consumer भी, termination detection की समस्या हल करनी पड़ी
    • idle thread atomic counter बढ़ाता है, और जब counter worker count तक पहुँच जाए और work queue खाली हो, तो पूरी processing समाप्त मानी जाती है
  • regex optimization और modern SSD speed की वजह से Veloren जैसे बड़े codebase में भी simple pattern search लगभग तुरंत पूरी हो जाती है
  • flamegraph में अधिकांश समय IO-bound दिखाई देता है
  • एडिटर के भीतर बड़े codebase को सोच की गति से search कर पाना productivity में बहुत मददगार है

terminal emulator buffer

  • pane-based editor में किसी एक pane को terminal window की तरह इस्तेमाल करने की सुविधा बहुत उपयोगी है
  • लेखक ने खुद ANSI parser लिखने की कोशिश की, लेकिन OSC52, Kitty keyboard extensions जैसे आधुनिक terminal rendering features का support बहुत विशाल निकला
  • alacritty_terminal crate का उपयोग करके Alacritty terminal emulator के escape sequence parser और terminal state management logic को reuse किया गया
  • नतीजतन, यह screen/tmux की core functionality को बदल सकता है, और उससे भी अधिक समृद्ध escape sequence support देता है

rendering optimization

  • TUI-based होने के बावजूद remote mobile connections पर bandwidth अब भी महत्वपूर्ण है
  • double buffering: terminal screen की internal copies दोहरी रखी गईं
    • redraw के समय previous frame से तुलना करके सिर्फ बदले हुए cells के लिए ANSI escape sequences output किए गए
    • cursor movement, style mode change जैसी sequences भी सिर्फ तब output होती हैं जब सच में ज़रूरत हो
  • ज़्यादातर terminal emulators (Ghostty को छोड़कर) में, एडिटर के terminal pane में बड़ी file को cat करने के बाद एडिटर बंद करना, host terminal में सीधे cat करने से ज़्यादा तेज़ था
    • क्योंकि alacritty_terminal host terminal के stdout byte processing cost को रोक देता है

निष्कर्ष: अपना खुद का टूल बनाइए

  • खुद बनाया गया एडिटर अब मेरे workflow पर पूरी तरह फिट बैठने वाला टूल बन चुका है
  • लेखक इस धारणा से असहमत है कि अपना एडिटर/टूल बनाना बेकार की पीड़ा है
  • चार फायदे बताए गए
    • पूर्ण अनुकूलन: टूल वही करता है जो चाहिए, न उससे ज़्यादा न कम
    • विविध तकनीकों की सीख: regex, ANSI, pseudoterminals (pty), TUI design, UTF-8 की बारीकियाँ आदि जैसी व्यापक रूप से उपयोगी तकनीकों की गहरी समझ मिलती है
    • दीर्घकालिक productivity gain: अपने टूल को पूरी तरह समझना और अपने workflow के हिसाब से फीचर बनाना, टूल के साथ friction कम करता है
    • शुद्ध आनंद: self-contained problems हल करने और उनके परिणाम को अपनी उँगलियों पर महसूस करने का अनुभव programming के प्रति प्रेम को फिर जगाता है, यहाँ तक कि वर्षों बाद कोड लिखते हुए खुलकर मुस्कुराने और अकेले हँस पड़ने जैसा अनुभव देता है
  • लेखक सलाह देता है कि टेक्स्ट एडिटर ही सही नहीं, अपना कोई न कोई टूल ज़रूर बनाइए, और मुश्किल हिस्सों को statistics box (AI आदि) के हवाले करने के बजाय चुनौती का आनंद लीजिए

संबंधित पढ़ाई

5 टिप्पणियां

 
xguru 2026-03-12

असल में, इस लेख में सबसे चौंकाने वाली चीज़ एक शब्द ही है।

Fingerspitzengefühl

Finger(उंगली) + Spitzen(सिरा) + Gefühl(संवेदना)

जर्मन भाषा में उंगलियों के सिरों की ऑपरेट करने की संवेदना को व्यक्त करने वाला एक शब्द होना सच में... आह..
 
carnoxen 2026-03-12

अरे, "Finger" भी जर्मन था। मुझे लगा था कि यह अंग्रेज़ी है...
 
mhcoma 2026-03-13

एक ही शब्द-परिवार होने के कारण बुनियादी शब्दावली काफ़ी हद तक साझा होती है।
 
yangeok 2026-03-12

जर्मन में तो शब्दों के अनंत combinations बन सकते हैं, हाहा
 
GN⁺ 2026-03-12
Hacker News की राय

  • यह पढ़ते हुए पूरे समय मज़ा आया। मैं अपने दोस्तों को भी खुद का text editor बनाने की सलाह देता हूँ
    मैं लगभग 10 साल से अपना editor ‘Left’ इस्तेमाल कर रहा हूँ। शुरुआत में यह परफेक्ट नहीं था, लेकिन Left से ही Left को सुधारते हुए इसे बेहतर बनाता गया। हर सुबह अपने हाथों से बनाए टूल को खोलने की जो खुशी मिलती है, वह लगाए गए समय का 20 गुना इनाम दे देती है

    • मैं भी 10 साल से ज़्यादा समय से अपना personal editor इस्तेमाल कर रहा हूँ। अपने लिए बिल्कुल फिट टूल के साथ दिन बिताना सच में बहुत सुकून देता है
    • मैं 19 साल से अपना editor ‘aoeui’ इस्तेमाल कर रहा हूँ। यह मेरी productivity बढ़ाने वाले सबसे असरदार फैसलों में से एक था
    • जानना चाहूँगा कि कौन-सी features सबसे ज़्यादा महत्वपूर्ण थीं। यह भी जानना है कि क्या इसे कई workflows को सपोर्ट करने के हिसाब से डिज़ाइन किया गया था

  • एक कहावत है, “ज़िंदगी में एक बार घर बनाना चाहिए, पेड़ लगाना चाहिए, और एक editor बनाना चाहिए।” मैंने आख़िरी वाले से शुरुआत की
    यह PicoLisp-आधारित Vi शैली के editor Vip में आने वाली पंक्ति है

  • मैंने भी शुरुआत से अपना text editor बनाया था। इसमें बहुत-सी features थीं, इसलिए LSP, tree-sitter, fzf जैसे external tools का सक्रिय रूप से इस्तेमाल किया।
    इसे suckless शैली में इस तरह डिज़ाइन किया कि सिर्फ़ code बदलकर customize किया जा सके।
    पहले कुछ हफ्तों तक इसमें ढेरों bugs थे, लेकिन ठीक करते-करते यह धीरे-धीरे stable होता गया। मेरा project hat देख सकते हैं

    • सही बात है। जब अतीत के fixes और improvements जमा होकर भविष्य की productivity acceleration में बदलते हैं, तो बहुत संतोष मिलता है

  • क्या कोई text editing library recommend कर सकता है?
    GUI ज़रूरी है, इसलिए font renderer और graphics context तक खुद संभालने पड़ेंगे।
    सिर्फ़ साधारण console के लिए हो तो वह मेरे काम की नहीं, और अगर सिर्फ़ GUI बनाऊँ तो editing features नहीं होंगी, इसलिए दोनों चाहिए।
    हैरानी की बात है कि इन ज़रूरतों को पूरा करने वाली शुद्ध API रूप की library मिलना मुश्किल है।
    ज़्यादातर या तो तैयार editors हैं, या बहुत बड़े framework स्तर की चीज़ें।
    बस ऐसा बुनियादी editing engine चाहिए जो बड़ी text files को तेज़ी से संभाल सके

    • इन दिनों terminal emulator कितने ताकतवर हो गए हैं, यह देखकर हैरानी हुई। clipboard, mouse events, focus tracking, notifications — लगभग सब कुछ संभव है।
      trolley जैसे tools से इसे ghostty-आधारित native UI की तरह wrap भी किया जा सकता है
    • कई lightweight GUI editors Scintilla पर बने हैं। यह GTK, Windows, Mac सबको सपोर्ट करता है। हालांकि इसमें features बहुत हैं, इसलिए simple API की तरह इस्तेमाल करने के लिए यह ज़रूरत से ज़्यादा हो सकता है
    • stb_textedit.h भी है, लेकिन मैं इसकी recommendation नहीं करूँगा। UTF-8 handling और word boundary detection जैसी चीज़ों में काफ़ी सीमाएँ हैं।
      इसकी जगह SDL और SDL_ttf का combination काफ़ी अच्छा विकल्प है। SDL3_ttf में string handling भी बेहतर हुई है
    • यह platform पर निर्भर करेगा, लेकिन अगर मकसद GUI rendering नहीं है तो raylib एक अच्छा विकल्प हो सकता है

  • मैंने antirez के “kilo” editor को फिर से implement किया था।
    मूल code और tutorial बहुत अच्छे हैं, इसलिए terminal mode और C भाषा की बुनियाद सीखने के लिए यह शानदार project था

  • 90 के दशक में COBOL और ASM files के लिए खुद editor बनाने की याद है।
    इसमें syntax highlighting, तेज़ buffering, और screensaver तक था।
    यह Pentium 120 पर चलता था, और याद पड़ता है कि आज के VSCode से हज़ार गुना तेज़ था

    • मैंने भी VB6 में editor बनाया था। 2002 के marketing page पर “unlimited templates, color printing, regex find/replace, code completion” जैसी features लिखी थीं।
      तब हम HTML tags सब uppercase में लिखते थे
    • पुराने laptop पर VSCode खोलो तो वह इतना धीमा लगता है कि दुख होता है। मैं vim पीढ़ी से हूँ, लेकिन आजकल के लोगों को उसे recommend करना आसान नहीं लगता
    • जानकारी के लिए, Borland Turbo Pascal और Turbo C भी एक साथ कई files खोल सकते थे

  • यह उस editor का लिंक है जो इस लेख के लेखक ने बनाया: zte

  • “मुश्किल हिस्सों को statistics box में ठेल देने के प्रलोभन का विरोध करो” — यह पंक्ति सच में बहुत प्रभावशाली लगी

  • मैं भी अपना custom editor इस्तेमाल करता हूँ। दूसरों को इसमें ज़्यादा दिलचस्पी नहीं होती, लेकिन खुद बनाए टूल से मिलने वाली value बहुत होती है

    • मैं भी अपनी programming language से बना editor इस्तेमाल करता हूँ। शुक्र है कि operating system खुद नहीं बनाना पड़ा
    • मैंने मौजूदा editor को modify करके अपने हिसाब से इस्तेमाल किया। इसमें image loading और scripting features भी हैं, और HTML tag matching color display भी है।
      F5 से links खोलने वाला एक simple ‘browser’ feature भी है
    • आपने link नहीं छोड़ा :(
    • मैं भी अपना editor इस्तेमाल करता हूँ। जब भी दोस्त स्क्रीन देखकर पूछते हैं, “यह क्या है?”, तो बड़ा गर्व महसूस होता है

  • Josh Barretto Super Mario 64 GBA port बनाने वाले जीनियस हैं। उनका editor हो तो मैं खुशी से आज़माना चाहूँगा

    • मुझे उनके SM64 videos पसंद हैं। जिसे जिज्ञासा हो, वह यह नया वीडियो देख सकता है