- Neovim कोड एडिटिंग को तेज़ टाइपिंग का काम नहीं, बल्कि नेविगेशन, बदलाव, हटाना, पुनर्गठन और टेस्ट जाँच के लगातार दोहराए जाने वाले लूप की तरह संभालने देता है
- Vim की editing grammar
ci\", dap, ., macro, text object जैसे अर्थ-आधारित ऑपरेशनों को जोड़कर दोहराए जाने वाले एडिटिंग कामों में घर्षण कम करती है
- Neovim explorer·terminal·Git panel को थोपता नहीं, बल्कि buffer को केंद्र में रखकर Telescope, Fugitive, LSP आदि को उपयोगकर्ता की पसंद के अनुसार चुनने देता है
- सेटिंग्स को Git में रखी फ़ाइलों के रूप में अपना बनाया जा सकता है, और वे shell·tmux·ripgrep·git·language server के साथ काम करने वाले सिस्टम के एक हिस्से के रूप में बनी रहती हैं
- Lua, built-in LSP, Treesitter, Lazy.nvim के साथ यह आधुनिक हुआ है, लेकिन इसका मूल मूल्य यह है कि सीखे हुए ऑपरेशन समय के साथ जमा होते जाते हैं और workflow खुद विकसित होता है
Vim से Neovim तक जारी रहने वाला काम करने का एहसास
- Vim का इस्तेमाल 2011 में शुरू हुआ था, और शुरुआत में
.vimrc कॉपी करने या यह समझने में भी दिक्कत थी कि j अक्षर टाइप क्यों नहीं करता बल्कि कर्सर क्यों चलाता है
- पहला हफ़्ता कठिन था और पहला महीना अजनबी लगा, लेकिन जब Vim का मॉडल सहज हो गया, तो दूसरे एडिटर ऐसे लगने लगे मानो कोड और उपयोगकर्ता के बीच कोई कुशनिंग परत हो
- VS Code, JetBrains IDE, Sublime, Atom, Zed जैसे कई एडिटर इस्तेमाल किए गए; JetBrains टूल बहुत शक्तिशाली हैं, और VS Code लगभग सभी के लिए काफ़ी अच्छा है तथा आसानी से extend किया जा सकता है, इसलिए वह सफल हुआ
- फिर भी Neovim को लगातार इस्तेमाल करने की वजह यह है कि वह काम करने के तरीके के मुताबिक चलता है और कोड एडिटिंग के दोहराए जाने वाले लूप को सीधे समर्थन देता है
एडिटिंग को शॉर्टकट नहीं, भाषा की तरह संभालने का तरीका
- कोड एडिटिंग तेज़ टाइपिंग का काम नहीं, बल्कि नेविगेशन, छोटे बदलाव, गलत abstraction हटाना, function को पुनर्गठित करना, फ़ाइलें सरकाना, और टेस्ट व diagnostics देखना जैसे बार-बार दोहराए जाने वाले कामों के ज़्यादा करीब है
- ज़्यादातर एडिटर टेक्स्ट को दस्तावेज़ की तरह और keyboard को input device की तरह देखते हैं, लेकिन Vim editing को grammar की तरह संभालता है
ci\" उद्धरण चिह्नों के भीतर की सामग्री बदलता है, dap एक paragraph हटाता है, और . पिछला बदलाव दोहराता है- macro किसी छोटे routine को एक बार सिखाकर पूरी फ़ाइल में दोहराकर लागू करने देते हैं, और text object काम को अक्षरों की गिनती के बजाय अर्थपूर्ण इकाइयों पर लागू करने देते हैं
- जब Vim की grammar हाथ में आ जाती है, तो माउस से कोड खींचना, sidebar पर क्लिक करना, या रोज़ दर्जनों बार होने वाले कामों के लिए command palette खोलना कम हो जाता है
- बार-बार होने वाले काम छोटे और सीधे मूवमेंट बन जाते हैं, और एडिटर का शोर भी घट जाता है
workflow को मजबूर न करने वाला Neovim
- GUI-केंद्रित एडिटर अक्सर explorer, terminal, Git panel और debugger की जगह व रूप को लेकर एक तय नज़रिया रखते हैं, और समय के साथ एडिटर cockpit जैसा लगने लगता है
- Neovim buffer से शुरू होता है, और उसके आसपास क्या रखना है यह उपयोगकर्ता तय करता है
- यदि file tree चाहिए तो जोड़ा जा सकता है, और fuzzy search के लिए Telescope या fzf-lua जैसे मनपसंद टूल चुने जा सकते हैं
- Git integration के लिए Fugitive इस्तेमाल किया जा सकता है, और LSP, diagnostics, formatting, snippet, Treesitter, test runner, autocomplete जैसी चीज़ें भी धीमे Electron dashboard में बदले बिना संभाली जा सकती हैं
- गति केवल startup time का नहीं, बल्कि भरोसे का सवाल है
- key दबाते ही तुरंत प्रतिक्रिया मिलनी चाहिए
- बड़ी फ़ाइल खोलते समय पूरा UI अटकना नहीं चाहिए
- SSH connection, tmux pairing, या छोटे terminal window में एडिट करते समय भी रोज़ इस्तेमाल होने वाले एडिटर जैसा ही एहसास बना रहना चाहिए
- local project, remote server, तेज़ config change, बड़ी Rails app, छोटी shell script, या Markdown लिखने तक, हर जगह वही movement, वही command, वही muscle memory इस्तेमाल की जा सकती है
- यह consistency पूरे करियर में जमा होती जाती है
अपना बनाया जा सकने वाला config और सिस्टम का हिस्सा बने रहने वाला टूल
- Neovim config Git में रखी फ़ाइलें हैं, इसलिए उन्हें सीधे पढ़ा जा सकता है, तोड़ा जा सकता है, और जब लगे कि कोई plugin ज़रूरी नहीं है तो उसका आधा हिस्सा मिटाया भी जा सकता है
- यह किसी रहस्यमय config database, आधी-अधूरी समझ वाले sync account state, या कुछ releases पहले बदले गए checkbox की वजह से background में अजीब व्यवहार करने वाले extension पर निर्भर नहीं करता
- आज के कई एडिटर हर काम का केंद्र बनना चाहते हैं, लेकिन Neovim बड़े सिस्टम का एक तेज़, सटीक हिस्सा बने रहने में ही संतुष्ट है
- यह shell को replace करने की कोशिश नहीं करता, बल्कि tmux, ripgrep, git, language server, formatter, linter, test runner के साथ मिलकर काम करता है
- पूरे desk पर कब्ज़ा करने की ज़रूरत न होना भी Neovim के लंबे समय तक टिके रहने की एक वजह है
- 2011 के बाद कई एडिटर, extension ecosystem, theme, marketplace, AI panel आए, लेकिन Vim तब भी पुराना और परखा हुआ टूल था, और Neovim ने लोगों द्वारा महत्वपूर्ण मानी गई वजहों को छोड़े बिना ज़रूरी हिस्सों को आधुनिक बनाया
आधुनिकीकरण और लंबे समय तक टिकने वाला learning reward
- Lua ने config को बेहतर बनाया है, और plugin ecosystem भी बहुत सुधरा है
- built-in LSP IDE फीचर्स को एडिटर में लाता है, लेकिन बिना इसे फूला हुआ महसूस कराए
- Treesitter ने syntax highlighting और code awareness को आधुनिक बनाया है, और Lazy.nvim ने plugin management को तेज़ और सरल बनाया है
- Neovim का सबसे बड़ा आकर्षण यह है कि समय बीतने पर भी सीखी हुई चीज़ें लगातार उपयोगी बनी रहती हैं
- एक motion सीखो, वह आगे भी मदद करता है
- macro लिखो, उबाऊ एडिटिंग गायब हो जाती है
- text object समझो, तो झुंझलाहट भरी refactoring आसान हो जाती है
- एक command को ठीक-ठाक ढालो, तो वह हाथ का हिस्सा बन जाती है
- एडिटर किसी कंपनी के नई sidebar जारी करने से बेहतर नहीं होता; वह तब बेहतर होता है जब उपयोगकर्ता उसे ज़्यादा कुशलता से संभालने लगता है
- productivity को सिर्फ “यहाँ 5 सेकंड बचा लिए” से मापना मुश्किल है; असली बात हज़ारों छोटे edits में घर्षण कम होने की है
- code, test, git diff और search result के बीच आते-जाते समय समस्या पर ध्यान बना रह सकता है, बिना यह लगे कि किसी दूसरे कमरे में चले गए हों
- Neovim अपनी programmability की वजह से default को बस स्वीकार करने के बजाय workflow को खुद आकार देने देता है
- यदि कोई असुविधाजनक चीज़ दो बार दोहराई जाए, तो उसे mapping, command, छोटे Lua function, बेहतर plugin, या plugin हटाकर आमतौर पर ठीक किया जा सकता है
- config काम करने के वास्तविक तरीके के अनुसार विकसित होता है, और जब मनचाहा बदलाव साफ़ दिखने लगे, तो सोच और एडिटिंग के बीच बहुत कम चीज़ें बचती हैं
- 15 साल में language, framework, machine performance और industry trends बदले हैं, लेकिन Vim और Neovim लगातार उस केंद्रीय एडिटर की तरह बने रहे हैं जहाँ सबसे अच्छा काम होता है
1 टिप्पणियां
Lobste.rs की राय
मैंने 12~14 साल पहले vim इस्तेमाल करना शुरू किया था, क्योंकि मुझे एक हल्का editor चाहिए था जो कोड को सामने ही दिखाए
मैंने mouse हटाकर सीखना शुरू किया, और बाद में यह जानकर अच्छा लगा कि Mitchell Hashimoto ने भी vim कुछ इसी तरह सीखा था
neovim के बारे में मुझे TJ DeVries(https://www.youtube.com/@teej_dv) और उनके YouTube चैनल के ज़रिए पता चला, जहाँ मैंने उन्हें neovim, telescope और कई दूसरे projects पर hack करते देखा
Lua की ओर बदलाव स्वाभाविक लगा, और यह पहले से ही मेरी पसंद की एक छोटी language थी इसलिए अच्छा लगा
मैंने सबसे पहले treesitter और telescope plugins इस्तेमाल किए थे, और आज भी कुछ छोटे plugins के साथ neovim इस्तेमाल कर रहा हूँ
neovim मेरे लिए कभी टूटा नहीं, यह बस ठीक से काम करता है। मैं LLM plugins इस्तेमाल नहीं करता, और मेरा मानना है कि उसका ecosystem editor के बाहर भी हो सकता है
उम्मीद है टीम आगे भी सिर्फ एक हल्का और focused code editor देती रहे
इसलिए neovim में Lua जुड़ना मुझे बहुत आकर्षक लगा
लगभग 20 साल पहले, मैंने यह सोचा था कि सिर्फ productive होने से अलग, रोज़मर्रा की ज़िंदगी को मज़ेदार बनाने वाली चीज़ें क्या हैं
उस सूची में सबसे ऊपर linux और vim थे
मैं कोई भी काम करूँ, कोई भी tech stack इस्तेमाल करूँ, ये दोनों हमेशा एक ergonomic, familiar और आरामदायक working environment देते थे
2009 में interview के दौरान मैंने
:wqसे आगे बढ़कर vim सीखना शुरू किया। वजह यह थी कि वहाँ के सभी कर्मचारी vim इस्तेमाल करते थे, इसलिए साथ काम करने का वही तरीका थाकुछ लोगों ने तो arrow keys तक disable कर रखी थीं
उससे पहले college के दिनों में मैंने बस
picoजैसा terminal editor इस्तेमाल किया था, और आम तौर पर उस समय के लोकप्रिय GUI editors का उपयोग करता थाअच्छी बात यह रही कि मेरी hiring हो गई, और तब से मैं vim लगातार इस्तेमाल कर रहा हूँ
हाल में मुझे एहसास हुआ कि vim जैसी सोच software life के दूसरे हिस्सों में भी फैल गई है
शायद इसकी शुरुआत macOS पर Hammerspoon के साथ window management के लिए submaps हेतु virtual keyboard बनाने से हुई, और पिछले साल के अंत में Arch Linux आज़माने पर tiling window management बहुत आसान हो गया
कुछ समय पहले मैं neovim पर आ गया था और मुझे यह सच में शानदार लगता है
editor jokes और debates बहुत हैं, लेकिन कुछ अपवादों को छोड़ दें तो मुझे अब भी समझना मुश्किल लगता है कि जो लोग coding को पेशे के तौर पर करते हैं, वे vim, emacs या वैसा कोई editor इस्तेमाल नहीं करते
किसी भी पेशे में काम के लिए सबसे अच्छा tool चुनना ज़रूरी है, और editing को एक language की तरह बरतना software में बहुत बड़ा फ़ायदा है
ऊपर वाले “समझना मुश्किल है” हिस्से पर कहूँ तो, VS Code जैसे editors का behavior, shortcuts और plugins भी बहुत उपयोगी हैं
VS Code का documentation ठीक से पढ़ना चाहिए, क्योंकि वह सच में बहुत कुछ कर सकता है
और कुछ लोगों के लिए, जिनमें मैं भी शामिल हूँ, mouse से buffer के किसी भी स्थान पर cursor ले जाना और किसी भी range को चुन लेना सरल है और काफ़ी तेज़ भी
KISS सही है
क्योंकि कई बार दूसरे editors उस काम के लिए बेहतर tool होते हैं
आजकल जिस Python का मैं सबसे ज़्यादा उपयोग करता हूँ, उसमें मुझे PyCharm उनसे बेहतर tool लगता है
अच्छी बात है कि IDEAVim नाम का एक बहुत अच्छा plugin है, जिससे muscle memory बनी रहती है
Mac पर इस्तेमाल करने पर system shortcuts, vi shortcuts से टकराते नहीं, इसलिए स्थिति के हिसाब से जो सही लगे वह चुन सकते हैं
C++ के लिए मुझे CLion बेहतर tool लगता है, लेकिन वहाँ भी IDEAVim काम करता है
जिन छोटे-मोटे कामों की category साफ़ नहीं होती, उनके लिए मैं अक्सर zed इस्तेमाल करता हूँ, और उसका vim emulation भी काफ़ी अच्छा है
remote systems में login करते समय एक अच्छा terminal editor होना निश्चित ही बढ़िया है, लेकिन जब पूरा GUI इस्तेमाल कर सकता हूँ तो terminal editor मुझे उतना पसंद नहीं आता
modal editing मुझे पसंद है, लेकिन अगर muscle memory छोड़ने की ज़रूरत नहीं है, तो GUI editor इस्तेमाल करने के भी पर्याप्त कारण हैं
VS Code बिना किसी बदलाव के भी कई कामों के लिए काफ़ी अच्छा है
इसमें पहले से ctrl-p file search, split panes, syntax highlighting, और popular languages का support है
मेरी इच्छा थी कि neovim कम से कम default में ctrl-p जैसा कुछ दे, और vim-style editor की दुनिया का Linux Mint जैसा कुछ बने, जहाँ security concerns और configuration barrier कम हों
SSH से जुड़ी machine पर tmux session में pair programming करते समय, या छोटे terminal window में किसी issue को ठीक करते समय, रोज़ इस्तेमाल होने वाले editor जैसा ही एहसास मिलना चाहिए — इस बात से मैं सहमत हूँ
मैंने SSH के ऊपर screen/vim के साथ बहुत सारा code लिखकर पैसे कमाए हैं, और यह उस दौर की बात है जब Slack जैसी लगातार बाधा डालने वाली चीज़ें हर समय नहीं बजती थीं, इसलिए तब सच में काफ़ी productivity होती थी
Visual Studio या Jetbrains IDEs जैसे CLion, Rider में जो visual debugger मिलता है, उसका अच्छा विकल्प मुझे किसी vim editor में नहीं मिला
उसमें cgdb जैसी चीज़ों की तुलना में ज़्यादा accessible power है
speed सिर्फ startup time का मामला नहीं है, और neovim इस मामले में अच्छा है, लेकिन default neovim का बंद होना vim की तुलना में स्पष्ट रूप से धीमा है
बहुत लंबा नहीं, लेकिन मेरे environment में इसमें लगभग 1 second लगता है
मुझे vim model पसंद है। modal editing उसका सिर्फ एक छोटा हिस्सा है, और helix या सामान्य IDEs की तुलना में vim को मैं इसलिए ज़्यादा महत्व देता हूँ क्योंकि इसे धीरे-धीरे सीखा जा सकता है
शुरुआत में key bindings और options समझते हैं, फिर Windows पर कुछ काम न करे तो config में conditionals जोड़ते हैं, फिर autocmds और functions लिखते हैं, और आगे चलकर पहले सीखी चीज़ों से छोटे plugins तक बना लेते हैं
फिर भी मैं vim या neovim से सच में प्यार नहीं करता
vim में दशकों से वही अजीब bugs बिना ठीक हुए पड़े हैं, और neovim ने कई bugs ठीक किए हैं लेकिन साथ ही कुछ नए bugs भी ले आया है
neovim का सबसे बड़ा पाप है हर update के साथ Lua API तोड़ देना
हर बार चलाने पर deprecation warnings देख-देखकर और जो काम करना था उससे पहले config ठीक करते-करते मैं थक गया हूँ
अगर कुछ नई features केवल Lua तक सीमित न होतीं तो शायद यह कम खलता
वरना मैं सिर्फ vimscript ही इस्तेमाल करता रहता और 20 साल से ज़्यादा चली आ रही compatibility से संतुष्ट रहता