क्या अभी भी कोई Emacs इस्तेमाल करता है?

 (jmmv.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1997 में Linux से परिचय के बाद Vim और Emacs के बीच आते-जाते रहने का अनुभव 2015 में VSCode और IntelliJ की ओर गया, फिर 2022 में Snowflake के remote Linux VM environment में Doom Emacs पर वापस लौट आया
  • VSCode ने modern UI, छोटा आकार, JSON-आधारित settings, और Go·Rust के लिए LSP integration के जरिए सीखना और development आसान बनाया, जबकि Java development में IntelliJ ज़्यादा practical विकल्प था
  • Snowflake के पुराने Linux VM में shell script और Bazel build file लिखना मुख्य काम था, और remote graphical environment की तुलना में SSH-आधारित काम ज़्यादा उपयुक्त था, इसलिए Emacs की फिर ज़रूरत पड़ी
  • Doom Emacs, reasonable defaults, language integration, Vim-style key bindings, space-आधारित popup menu, और simple settings file structure की वजह से Emacs को IDE जैसा महसूस कराता है
  • MacBook, Linux laptop, Linux cloud workstation, और FreeBSD server—कहीं भी shell·tmux·Emacs से एक जैसा development environment बनाए रख पाना ही Emacs का इस्तेमाल जारी रखने की सबसे बड़ी वजह है

DOS/Windows IDE से Linux editor तक

  • लगभग 1997 में Caldera OpenLinux 1.1 के साथ Linux से परिचय हुआ
  • उससे पहले Borland Turbo C++ और Visual Basic का बहुत इस्तेमाल किया था, इसलिए उस समय के polished IDE की आदत थी
  • Linux पर शुरुआती दो किताबों के ज़रिए Vim और Emacs से परिचय हुआ, और दोनों editors को advanced विकल्प के रूप में पेश किया गया था
  • पहले इस्तेमाल किए गए IDE ज़्यादा complete लगते थे, लेकिन Vim और Emacs दोनों के basic usage और tutorial अलग-अलग सीखे
  • लगभग 2015 तक Vim और Emacs को बारी-बारी से इस्तेमाल किया
    • लंबे coding sessions में Emacs ज़्यादा अनुकूल था
    • Vim, pkgsrc जैसे कामों में कई files के बीच तेज़ी से घूमकर edits करने में मज़बूत था

VSCode और IntelliJ की ओर जाने की वजह

  • Vim और Emacs पर्याप्त रूप से काम करते थे, लेकिन language integration कमज़ोर थी, इसलिए ज़्यादा modern editor में रुचि हुई
  • macOS पर जाने के बाद Atom और Brackets भी आज़माए, लेकिन features और settings बहुत ज़्यादा होने से वे fragile और बोझिल लगे
  • 2015 में आया VSCode शुरू से ही सही tool जैसा लगा
    • यह modern दिखता था और अपेक्षाकृत छोटा था
    • उस समय settings editor, settings panel के बिना JSON file-आधारित था, इसलिए control करना आसान लगा
  • Go और Rust सीखना शुरू करने पर VSCode का हर language के लिए LSP integration बहुत मददगार साबित हुआ
    • code autocomplete
    • real-time error highlighting
    • सीखने की रफ़्तार में बढ़ोतरी
  • Google में Bazel नाम के Java project पर काम करते समय IntelliJ स्वाभाविक विकल्प था
    • Emacs से Java development की कोशिश भी की थी, लेकिन IntelliJ इतना अच्छा था कि practical विकल्प वही था
  • Microsoft में C++ codebase और remote Windows machine पर काम करते समय भी VSCode और Vim plugin का इस्तेमाल जारी रखा
    • कई लोग RDP के ज़रिए remote machine पर सीधे काम करते थे
    • local desktop पर VSCode चलाकर SSH से remote machine में जाना ज़्यादा पसंद था

Snowflake में Doom Emacs पर लौटने का कारण

  • 2022 में Snowflake जाने के बाद development पुराने Linux VM के भीतर होता था, और रोज़मर्रा का काम shell script और Bazel build file लिखना था
  • इस environment में VSCode या IntelliJ कोई खास समस्या हल नहीं कर रहे थे, और remote graphical environment की सीमाएँ भी पसंद नहीं थीं, इसलिए SSH से local VM में जुड़ने वाले तरीके पर वापसी हुई
  • लंबे work sessions के लिए फिर से editor की ज़रूरत पड़ी, और विकल्प Emacs था
  • पुरानी init.el में वर्षों से जमा सैकड़ों lines की settings थीं, लेकिन उन्हें पूरी तरह समझते नहीं थे, इसलिए सब छोड़कर नए सिरे से शुरू करना चाहते थे
  • इसी समय Doom Emacs मिला
    • Doom Emacs, Emacs का पहले से configure किया हुआ एक “distribution” है
    • यह reasonable defaults देता है
    • pre-defined language integration देता है
    • ex-Vim users के लिए familiar अनुभव देता है
    • यह खुद को IDE नहीं कहता, लेकिन असली usage experience IDE जैसा लगता है

Doom Emacs ने usage experience कैसे बदला

  • Doom Emacs सेट करने के बाद Emacs फिर से 2015 के VSCode की तरह “सही tool” जैसा लगा
  • Emacs की कई features, space-आधारित shortcuts के बाद आने वाले interactive popup menu के ज़रिए सामने आती हैं, इसलिए उन्हें ढूँढना आसान हो गया
  • यह Vim-style key bindings के साथ सह-अस्तित्व रखते हुए कलाई पर कम दबाव डालने वाला shortcut flow देता है
  • settings तीन सरल files में बँटी होती हैं
    • config.el: theme, font जैसी global settings तय करता है
    • init.el: सक्रिय करने के लिए Doom-specific modules चुनता है
    • packages.el: Doom में शामिल न होने वाले packages install करता है
  • defaults reasonable हैं, और जिन details को tweak किया जा सकता है, उन पर पर्याप्त comments भी दिए गए हैं
  • LSP की प्रगति और tree-sitter जैसी modern features की वजह से Emacs अब IDE जैसा महसूस होता है
    • जिन ज़्यादातर languages से काम पड़ता है, उनमें proper language integration मिल जाती है

हर जगह एक जैसा development environment होने का महत्व

  • सबसे ताकतवर feature यह है कि किसी भी machine पर काम करें, एक जैसा development environment मिलता है
  • काम की machines में MacBook, Linux laptop, Linux cloud workstation, और व्यक्तिगत FreeBSD server तक शामिल हैं
  • ज़रूरत सिर्फ shell, tmux, और Emacs की होती है
  • अलग-अलग machines पर काम करते समय एक जैसा environment और muscle memory सीधे productivity में मूल्य जोड़ते हैं
  • इसी ज़रूरत की वजह से Emacs पहले से भी अधिक महत्वपूर्ण tool बन गया है

क्या Doom Emacs बहुत ज़्यादा काम करता है?

  • Doom Emacs पर “बहुत ज़्यादा काम करता है” जैसी शिकायतें हैं, लेकिन वास्तव में वही इसकी उपयोगिता भी है
  • कभी न कभी Emacs को खुद ज़्यादा सीखने के लिए configuration कम करने पर विचार करने का मन होता है
  • कई modern third-party modules का default Emacs packages में शामिल होते जाना भी इस सोच को बढ़ाता है
  • हाल में Bedrock या Emacs Solo distribution आज़माने का मन भी हुआ है
  • लेकिन बदलाव के लिए ज़रूरी activation energy काफ़ी अधिक है, और अगर उस रास्ते पर भी जाएँ, तो आख़िर “raw” Emacs तक क्यों न जाएँ—यह सवाल फिर सामने आता है

Elisp, Org mode, और Magit के प्रति दूरी

  • Emacs का Elisp-आधारित होना लोगों के workflow को किस तरह गहराई से बदल देता है, यह अभी भी पूरी तरह समझ में नहीं आया है
  • Emacs के भीतर ज़्यादा logic और workflow लागू किए जा सकते हैं, लेकिन shell script से पहले ही लगभग हर काम आसानी से हो जाता है
  • script, “Unix is my IDE” वाले नज़रिए से ज़्यादा Unix-जैसी लगती है
  • Org mode और Magit का standalone application न होकर Emacs के पीछे बँधा होना पसंद नहीं आता
  • जब तक अलग-अलग remote machines पर लगातार काम करने की ज़रूरत बनी रहेगी, Emacs एक महत्वपूर्ण tool बना रहेगा

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • मैंने यह पोस्ट इसलिए लिखी क्योंकि विषय बहुत मज़ेदार लगा
    किसी खास सवाल की वजह से नहीं, बल्कि इसलिए कि मैं देख रहा हूँ कि कंपनियों में ऊँचे पदों पर बैठे लोग CLI-आधारित coding agent इस्तेमाल करते-करते command-line tools को “खोज” रहे हैं, और फिर यह दिखाने की कोशिश कर रहे हैं कि उनकी यह नई खोज कितनी उपयोगी है
    अभी तक tmux इसका सबसे बड़ा उदाहरण है, और अब मैं बस इस इंतज़ार में हूँ कि उन्हें जल्द ही यह भी पता चले कि Vim और Emacs भी मौजूद हैं
    ये tools बहुत लंबे समय से हमारे आसपास रहे हैं, और अगर आप कंपनी के “उच्चस्तरीय 10x developer” से पूछें तो वह शायद कहेगा कि वह इन्हें इस्तेमाल करता है
    फिर भी इन्हें अक्सर “हाहा, वह तो प्राचीन अवशेष है। चलो web पर चलते हैं!!11” जैसा समझा गया
    शायद कोई वजह रही होगी कि वे developers इन tools का इस्तेमाल करते रहे ;P

    • “low-quality generated content bubble” की एक अच्छी बात यह है कि plain text फिर से एक वैध और महत्वपूर्ण माध्यम बनता दिख रहा है
      इसमें CLI का ज़्यादा आम होना और पहले सिर्फ़ सुन-सुनकर चलने वाला बहुत-सा ज्ञान अब दस्तावेज़ित होना भी शामिल है। बेशक, यह मानकर कि वह ज्ञान इंसानों ने बनाया हो
      उम्मीद है कि यह मुश्किल दौर निकल जाने के बाद भी ये अच्छे हिस्से बने रहेंगे
    • Emacs users में से ज़्यादातर शायद इसे GUI में ही इस्तेमाल करते होंगे
      मेरे पास संख्या नहीं है, लेकिन मुझे लगता है कि बहुत भारी बहुमत ऐसा ही होगा

  • मैं भी अब इसे सीखना शुरू करने वालों में शामिल हूँ
    कुछ साल पहले मैंने Doom Emacs आज़माया था, लेकिन वह latency इतनी धीमी थी कि परेशान होकर छोड़ दिया। native compilation की वजह से क्या अब वह पुरानी बात हो गई है, यह नहीं जानता, और अभी बिना किसी config वाले plain Emacs में होने की वजह से महसूस करना भी मुश्किल है। मैं Nixpkgs का 30.2 इस्तेमाल कर रहा हूँ, और लगता है कि इसमें native compilation default से चालू है
    Emacs में email लिखने जैसी चीज़ों में मेरी खास दिलचस्पी नहीं है; मुझे बस ऐसा editor चाहिए जिसे मैं अपनी पसंद के मुताबिक ढाल सकूँ। बाद में अगर Lisp सीखना चाहूँ तो उसके लिए भी काम आए, और शायद वह Janet होगा। Helix में अभी plugin नहीं हैं, इसलिए Lisp के मामले में विकल्प लगभग नहीं के बराबर हैं। “सब कुछ text है” वाली philosophy भी मुझे पसंद है, लेकिन असल में वह मेरे लिए कितनी जमेगी, यह देखना होगा
    2026 में इसे सीखना थोड़ा भारी भी लगता है। दशकों से जमा हुई implicit knowledge की वजह से जब कुछ पढ़ते हैं तो package names, command names वगैरह हर तरफ़ उछलते मिलते हैं, और आप तो बस $THING करना चाहते हैं, लेकिन उल्टा दबाव महसूस होने लगता है। इसलिए guided learning path के तौर पर मैंने Mastering Emacs उठाई
    default key bindings भी काफ़ी अजीब हैं। पता है कि सब कुछ दोबारा bind किया जा सकता है, लेकिन उससे काम बढ़ता है। ऊपर से मैं अपना split ergonomic keyboard खुद बनाता हूँ, और firmware भी Vim/Helix-शैली के workflow के हिसाब से ट्यून कर रखा है, जहाँ modifier keys core flow का हिस्सा नहीं होतीं
    मैं MacBook Pro, PC, और custom keyboard — इन तीनों के बीच आता-जाता रहता हूँ, इसलिए ऐसा consistent key binding चाहिए जिससे दिमाग़ न पिघले। hjkl हर keyboard पर एक ही जगह रहता है, लेकिन Ctrl जैसी keys नहीं

    • अगर key bindings मुश्किल लग रही हों और आप Vim की तरफ़ ज़्यादा सहज हों, तो evil देखना ठीक रहेगा
      हो सकता है आपको यह ताना सुनने को मिले कि evil उन Vim शरणार्थियों के लिए है जो “Emacs का सच्चा सुसमाचार” सीखना नहीं चाहते, लेकिन Emacs का सच्चा सुसमाचार® तो यही है कि आप इसे अपने लिए सबसे बेहतर तरीके से इस्तेमाल करें
      मैं 1998 से Emacs इस्तेमाल कर रहा हूँ, और बिल्कुल भी Vim प्रेमी नहीं था। 2011 के आसपास मुझे wrist repetitive strain की थोड़ी समस्या हुई, तो उसे कम करने वाले packages आज़माए। कुछ साल तक मैंने god mode बहुत इस्तेमाल किया, लेकिन वह फिर भी अटपटा लगा
      फिर मैंने evil सिर्फ़ “यह साबित करने के लिए कि यह काम नहीं करेगा” आज़माया, जबकि मैंने ज़िंदगी में कभी Vim इस्तेमाल नहीं किया था। लेकिन एक हफ़्ते में ही मैं god mode जितना सहज हो गया, और एक महीने बाद तो official Emacs key bindings की तुलना में भी तेज़ हो गया
      इसका मतलब यह नहीं कि default key bindings ग़लत हैं। बस मेरी कलाई अच्छी नहीं है, इसलिए आपका अनुभव अलग हो सकता है। boon या meow भी आपके लिए बेहतर बैठ सकते हैं
      लेकिन अगर evil आपके लिए काम करता है, तो ज़रा भी guilt महसूस करने की ज़रूरत नहीं है। Emacs कभी-कभी user को बदलता है, लेकिन उससे कहीं ज़्यादा Emacs खुद user के लिए बदल जाता है
    • Doom इस बात पर बहुत निर्भर करता है कि आप उसे कैसे configure करते हैं। और वह हिस्सा समय के साथ लगातार बेहतर भी हुआ है
      सबसे अच्छा तो खुद से setup बनाना है, लेकिन उसमें काफ़ी काम लगता है, और Doom जैसे projects new user onboarding को सच में आसान बना देते हैं
    • default key bindings का अजीब होना ही मुझे Doom Emacs में उल्टा पसंद आया
      पहले मैं default Emacs key bindings काफ़ी जानता था, लेकिन वे मुझे कभी natural नहीं लगीं, और खासकर discoverability बहुत कम थी
      Doom Emacs लगभग हर काम के लिए SPC prefix key इस्तेमाल करता है, और अगर आप एक पल रुकें तो एक temporary menu खुल जाता है जो बताता है कि आगे कौन-सी completions संभव हैं, जो काफ़ी अच्छा है। इससे वे features भी मिल जाते हैं जिनके बारे में पता नहीं था, और यह Vim modal mode से भी नहीं टकराता
      इसलिए text editing के लिए Vim mode और Emacs operations के लिए SPC combinations — यह setup मुझे अच्छा संतुलन लगा
      default Emacs key bindings के अपने फ़ायदे भी हैं। basic text manipulation keys readline, और यहाँ तक कि macOS के साथ भी साझा होती हैं। macOS की Emacs-शैली text management keys VSCode तक पहुँची हुई हैं, और standard clipboard keys से भी नहीं टकरातीं, इसलिए macOS पर VSCode काफ़ी अच्छा लगा
      लेकिन Windows और Linux पर जाने के बाद, Vim plugin के बिना VSCode सहना मेरे लिए लगभग नामुमकिन हो गया
    • अगर आप Helix से आए हैं, तो meow भी देख सकते हैं
      सुना है कि यह Kakoune और Helix जैसे features default से देता है, और कम दखल देने वाला है। मैंने दोनों खुद इस्तेमाल नहीं किए हैं, इसलिए यह सुनी-सुनाई बात पर आधारित है
      जो evil package recommend किया गया था, उसके बारे में मेरा मानना है कि वह key bindings पर बहुत ज़्यादा क़ब्ज़ा कर लेता है और बाहरी packages के साथ उतना अच्छे से नहीं घुलता-मिलता, इसलिए बहुत-से “adapter” packages की ज़रूरत पड़ती है
      meow को एक बार configure करने के बाद वह काफ़ी कम झंझट वाला लगा

  • मैं इसे 33 साल से इस्तेमाल कर रहा हूँ, और यह editor या IDE से जो भी चाहिए, सब कर देता है

  • Doom और (n)vim के बीच आते-जाते रहने के बाद, हाल में ज़्यादातर Neovim पर टिक गया हूँ
    Emacs इस्तेमाल करते हुए जो मुख्य समस्या झेली, वह मज़ेदार ढंग से यह थी कि उसका maintenance बहुत पीड़ादायक था। Doom को upgrade करते ही package sync बिगड़ जाती थी और अक्सर पूरी तरह reinstall करने वाले nuclear option के अलावा कुछ नहीं बचता था
    बेशक इसे और “कम नौसिखिया तरीके” से ठीक किया जा सकता था, लेकिन एक समय के बाद बस यही चाहत रहती है कि टूल काम करे। काम करना है, लेकिन config टूट जाए और editor पर ज़रूरत से ज़्यादा निर्भरता हो, तो उसे संभालना मुश्किल होता है
    फिर भी org-mode और Emacs का कुल मिलाकर navigation का तरीका याद आता है
    हर बार जब भी VSCode, CLion जैसे “modern” समाधान आज़माता हूँ, वही समस्याएँ और ज़्यादा मिलती हैं। ठीक-ठाक accessibility features नहीं हैं, इसलिए pure keyboard navigation की जगह अटपटे ढंग से क्लिक करना पड़ता है, और “Vim” behavior भी असली चीज़ के मुकाबले अधूरा लगता है
    आजकल Neovim इसलिए इस्तेमाल कर रहा हूँ क्योंकि यह बस ठीक से काम करता है। सच कहूँ तो अगर coding agent से 2 मिनट के लिए config ठीक करवा ली होती, तो शायद आज के Emacs के बारे में भी यही कह सकता था (:

    • Doom का update feature कुछ बार आज़माया, लेकिन हर बार समस्या आई
      आजकल जब भी upgrade करना हो, या Emacs upgrade की वजह से ज़रूरत पड़े, तो rm -rf ~/.emacs.d/ से मिटाकर Doom को शुरू से सेट करता हूँ। ~/.doom.d/ को version control में रखा है
      इस workflow में कोई दिक्कत नहीं हुई

  • मैं उन अजीब लोगों में से हूँ जो development, writing, email सब Emacs में करते हैं, और ऐसा करते हुए लगभग 15 साल हो गए, लेकिन elisp सीखने का समय या फुर्सत कभी नहीं निकाल पाया
    config file छेड़ते समय भी सच में ठीक से नहीं पता होता कि क्या कर रहा हूँ। फिर भी यह अब भी मेरा सबसे productive environment है, और यही दिखाता है कि यह editor कितना शानदार है :-)
    Mastering Emacs को ठीक से पढ़ना शर्म की हद तक लंबे समय से मेरी todo list में पड़ा है

    • मेरा भी लगभग यही हाल है। config ठीक करते-करते और edit करते-करते osmosis की तरह elisp थोड़ा-बहुत आ गया, लेकिन सच में जो जानता हूँ वह इतना कम है कि थोड़ा शर्मिंदगी होती है
    • M-x high-five
      मेरे मामले में भी मैं बहुत कम packages इस्तेमाल करता हूँ और default key bindings ही रखता हूँ। असल में कोई high-five function है नहीं, लेकिन शायद इसी बहाने आखिरकार elisp में गहराई से उतरूँ

  • Vim rendering पसंद नहीं आई और Electron/VSCode जैसी चीज़ों से भी ऊब गया, इसलिए लगभग 2 साल पहले Emacs पर आ गया
    avy और कुछ jump plugins ने आकर्षित किया, लेकिन जिसने मुझे जोड़े रखा और आज भी code changes के लिए primary tool बनाए रखा है, वह magit है

  • काम में जिन clients से पाला पड़ता है, उनका पूरा business बहुत बड़ी CSV files के इस्तेमाल पर टिका है, लेकिन वहाँ ऐसा लगता है कि 1GB file का data खोलना या देखना किसी को नहीं आता
    CSV header माँगने पर इस्तेमाल करने वाला head command तक नहीं पता

  • कई सालों तक X/GUI में इस्तेमाल किया, और अभी-अभी -nw पर switch किया है
    presentation के समय ही Pgtk version इस्तेमाल करता हूँ