रिमोट सर्वर डेवलपमेंट के लिए Helix एडिटर का उपयोग कैसे करें

 (rushter.com)
7 पॉइंट द्वारा GN⁺ 2025-10-14 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • रिमोट सर्वर डेवलपमेंट के लिए Helix को चुनने का कारण यह है कि इसे Vim/Neovim की तरह दर्जनों प्लगइन इंस्टॉल किए बिना इस्तेमाल किया जा सकता है, जिससे सप्लाई-चेन अटैक का जोखिम कम होता है
  • tmux इंटीग्रेशन सेटअप के जरिए Helix में कमी महसूस होने वाले फ़ाइल एक्सप्लोरर और Git TUI फीचर्स की भरपाई की गई, और yazi फ़ाइल मैनेजर, lazygit आदि को पॉपअप में चलाने लायक कॉन्फ़िगर किया गया
  • Vim स्टाइल keybinding पोर्ट करके लाइन चुनना, कर्सर मूव करना, टेक्स्ट डिलीट करना जैसी क्रियाओं को Vim जैसा व्यवहार देने के लिए सेट किया गया, और ESC से multi-cursor रीसेट होने के लिए बदला गया
  • statusline में Git branch, encoding, position जैसी जानकारी जोड़कर उत्पादकता बढ़ाई गई
  • Tree-sitter injection का उपयोग करके Python/Go के भीतर की SQL queries, Markdown के code block आदि पर syntax highlighting लागू कर पठनीयता बेहतर की गई
  • LSP, auto-save, color mode जैसी उन्नत सेटिंग्स का उपयोग करके काम की उत्पादकता बढ़ाई गई और बारीकी से customization किया गया

Helix चुनने की पृष्ठभूमि

  • हाल के सप्लाई-चेन अटैक में वृद्धि और plugin dependency समस्याओं के कारण Vim/Neovim की जगह Helix को रिमोट सर्वर डेवलपमेंट एडिटर के रूप में अपनाया गया
  • Neovim के दर्जनों प्लगइन के बिना भी सिर्फ बेसिक फीचर्स से इस्तेमाल हो सकना इसका बड़ा फायदा है
  • Helix पर स्विच करने के बाद, परिचित Neovim अनुभव को जितना संभव हो सके पुनः बनाने के लिए configuration customization किया गया
  • इसे साझा करने का उद्देश्य दूसरे उपयोगकर्ताओं का समय बचाना है

Tmux सेटअप

  • terminal multiplexer के रूप में Tmux का उपयोग किया जाता है, और फ़ाइल मैनेजर व Git TUI की कमी दूर करने के लिए custom keybinding जोड़ी गई
  • Helix फ़ाइल एक्सप्लोरर में फ़ाइल एडिटिंग सपोर्ट नहीं करता, इसलिए कई फ़ाइलों के बीच तेज़ी से जाना असुविधाजनक था
  • Tmux config फ़ाइल में निम्न binding जोड़ी गई
    • prefix - y: Yazi फ़ाइल मैनेजर को popup विंडो में चलाना (स्क्रीन के 95% आकार में)
    • prefix - g: Lazygit को popup विंडो में चलाना
    • prefix - e: Tmux output history को Helix एडिटर में खोलकर search और copy का काम करना
  • डिफ़ॉल्ट prefix Ctrl + b है, लेकिन इसे Ctrl + \ में बदलकर उपयोग किया जा रहा है
  • terminal output से जुड़े कामों में यह उपयोगी है, खासकर ClickHouse client output (CSV/JSON) को Slack में कॉपी करते समय
    • फ़ाइल में आउटपुट लिखने के बजाय सीधे कॉपी किया जा सकता है, जिससे काम के चरण कम होते हैं
    • माउस से भी किया जा सकता है, लेकिन Tmux buffer scroll असुविधाजनक होने के कारण एडिटर में करना अधिक प्रभावी है
  • Yazi और Lazygit आमतौर पर Helix एडिटर के ऊपर overlay के रूप में दिखते हैं

Vim keybinding पोर्ट करना

  • Helix keybinding की आदत हो चुकी है, लेकिन फिर भी कुछ Vim binding पोर्ट करके उपयोग किए जा रहे हैं
  • Select mode binding
    • 0: लाइन की शुरुआत पर जाना
    • $: लाइन के अंत पर जाना
    • ^: पहले non-whitespace character पर जाना
    • G: फ़ाइल के अंत पर जाना
    • D: लाइन के अंत तक select करके delete करना और normal mode में जाना
    • k/j: ऊपर/नीचे की पूरी लाइन select करना (Helix का डिफ़ॉल्ट व्यवहार partial selection है, जो असुविधाजनक लगा)
  • Normal mode binding
    • D: कर्सर के दाईं ओर का पूरा टेक्स्ट delete करना (Helix में इसके लिए बहुत अधिक key input चाहिए, इसलिए इसे पोर्ट किया गया)
    • V: Select mode में जाकर पूरी लाइन select करना
    • ESC: multi-cursor reset (Helix का डिफ़ॉल्ट comma है, जो असुविधाजनक लगा)
  • Helix का visual mode line selection तरीका पसंद नहीं आया, इसलिए इसे Vim स्टाइल में बदला गया
    • ऊपर/नीचे जाने पर पूरी लाइन select हो, इसके लिए सेट किया गया

बेहतर status bar

  • डिफ़ॉल्ट status bar में मौजूदा Git branch जैसी महत्वपूर्ण जानकारी की कमी है
  • status bar configuration
    • बायाँ: mode, spinner, version control, filename, read-only indicator, modified indicator
    • मध्य: खाली
    • दायाँ: diagnostics, workspace diagnostics, position, कुल लाइन संख्या, position percentage, file encoding, line ending format, file type, register, selection count
    • separator: │ character का उपयोग
  • काम की स्थिति एक नज़र में समझी जा सकती है

उपयोगी keybinding

  • custom keybinding से काम की दक्षता में बड़ा सुधार हुआ, हालांकि इन्हें ढूँढने में समय लगा
  • सबसे उपयोगी फीचर्स: file reload, soft wrap toggle, Git undo, Git blame, Git diff
  • पूरी custom binding सूची
    • space - e - w: मौजूदा buffer को फ़ाइल के रूप में सेव करना
    • space - e - c: मौजूदा buffer बंद करना
    • space - e - x: बाकी सभी buffer बंद करना (दर्जनों buffer खुले हों तो उपयोगी)
    • space - e - l: inlay type hints toggle (उपयोगी, लेकिन हमेशा दिखने पर बहुत noise पैदा करता है)
    • + - f: मौजूदा फ़ाइल format करना
    • + - w: whitespace character rendering (दस्तावेज़ में अदृश्य characters देखने के लिए)
    • + - W: whitespace character rendering बंद करना
    • space - f - .: file picker में Git ignored files दिखाना/छिपाना
    • space - f - r: सभी फ़ाइलें reload करना (Helix auto reload सपोर्ट नहीं करता, इसलिए बाहरी बदलाव या commit के बाद gutter अपडेट के लिए बहुत उपयोगी)
    • space - f - x: मौजूदा कर्सर पर Git change undo
    • space - f - w: मौजूदा लाइन का Git blame दिखाना
    • space - f - d: Git diff दिखाना

एडिटर सेटिंग्स

  • 6 महीने उपयोग करने के बाद पता चला कि terminal tab बदलने पर auto-save फीचर मौजूद है
  • Helix की कुछ नई सुविधाएँ डिफ़ॉल्ट रूप से disabled होती हैं, ताकि पुराने उपयोगकर्ताओं को अचानक बदलाव का सामना न करना पड़े
  • नई सुविधाएँ खोजने के लिए हर option को खुद देखना पड़ता है
  • मुख्य configuration options
    • line-number = "relative": relative line numbers दिखाना
    • rulers = [120]: visual vertical ruler सेट करना (auto format के बिना अधिकतम line length सीमित करने में उपयोगी)
    • true-color = true: true color को force enable करना
    • completion-replace = true: auto-completion पूरे शब्द को replace करे
    • trim-trailing-whitespace = true: trailing whitespace हटाना
    • color-modes = true: mode indication को रंगों से अलग करना
    • rainbow-brackets = true: nested brackets के लिए अलग-अलग रंग (नई सुविधा, अभी औपचारिक release से पहले)
    • editor.file-picker.hidden = false: file picker में hidden files (dot files) दिखाना
    • editor.indent-guides.render = true: visual indent guides जोड़ना
    • editor.inline-diagnostics.cursor-line = "warning": diagnostics display बेहतर करना (स्क्रीनशॉट देखें)
    • editor.auto-save.focus-lost = true: focus खोने पर auto-save (terminal support आवश्यक)
    • editor.auto-save.after-delay.enable = true: तय delay के बाद auto-save (300 सेकंड पर सेट)

LSP समायोजन

  • सभी भाषाओं के लिए harper-ls LSP जोड़ा गया, ताकि comments के भीतर grammar errors highlight हो सकें

कस्टम Tree-sitter injection

  • Helix custom Tree-sitter injection निर्दिष्ट करने की अनुमति देता है, जिससे एक भाषा के भीतर दूसरी भाषा को highlight किया जा सकता है
  • उपयोग के मामले
    • Python और Go के भीतर SQL queries की syntax highlighting
    • Markdown में YAML front matter और code blocks highlighting
    • HTML snippets highlighting में भी उपयोग संभव
  • GitHub पर configuration files अपलोड करके custom injection और settings साझा की गई हैं
  • Helix कम से कम plugins, बेहतर security, और सहज customization जैसी खूबियों वाला एक अगली पीढ़ी का terminal editor है

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

2 टिप्पणियां

 
xguru 2025-10-14

20 साल तक Vim इस्तेमाल करने वाले एक डेवलपर का Vim से Helix पर स्विच करने का अनुभव
 
GN⁺ 2025-10-14
Hacker News टिप्पणियाँ

  • मैं हाल ही में अपना editor setup फिर से बना रहा हूँ। 20 साल से Emacs और 15 साल से Vim दोनों साथ में इस्तेमाल कर रहा हूँ, और अब तक इनमें से एक को चुन नहीं पाया हूँ। मेरा लक्ष्य यह देखना है कि enterprise-grade Python software पर तुरंत काम शुरू करने लायक एक complete setup कितनी जल्दी बनाया जा सकता है। इस बार खास तौर पर कोशिश यह है कि third-party extensions पर निर्भरता को जितना हो सके कम किया जाए और सिर्फ ज़रूरी features रखे जाएँ। मेरा मौजूदा Neovim setup मुझे अब तक का सबसे अच्छा लगता है, लेकिन इसमें उम्मीद से ज़्यादा plugins लग गए। Emacs के मामले में अभी मैं शुरुआती चरण में हूँ, लेकिन यह दिलचस्प है कि version 30+ में यह इतना आगे बढ़ गया है कि third-party plugins की ज़रूरत काफी कम हो गई है। पहले मैं lsp-mode इस्तेमाल करता था, लेकिन अब Eglot से संतुष्ट हूँ। completion preview mode भी corfu को पूरी तरह replace तो नहीं करता, लेकिन काफी अच्छा है। Emacs के लिए मेरी जरूरी plugin list है: Magit, Expreg(treesitter expand region), Multiple cursors, dape(Eglot के साथ debugging)। शायद Consult और orderless भी जोड़ूँगा। मेरा Neovim setup यहाँ देखा जा सकता है

    • नया nvim भी धीरे-धीरे plugins की ज़रूरत कम कर रहा है। built-in plugin manager, diff viewer, और lsp सब मिलते हैं

    • आप काफी सारे nvim plugins संभाल रहे हैं! मैंने पिछले हफ्ते अपना nvim setup फिर से लिखा और उसे mini.nvim समेत सिर्फ 4 plugins तक सीमित किया। मुझे लगा कि plugins ज़्यादा जोड़ने पर nvim की stability और reliability काफी गिर जाती है। Emacs में सिर्फ 2 plugins की ज़रूरत पड़ना वाकई ईर्ष्या करने लायक है, और वह निश्चित ही ज्यादा stable चलेगा। मेरा setup यहाँ देखा जा सकता है

    • क्या आपको लगता है कि कुछ महीनों तक इस्तेमाल करने के बाद भी यह Pycharm+IdeaVIM के default built-in setup जितने स्तर तक पहुँचता है? बेशक खुद settings के साथ छेड़छाड़ करने में मज़ा है, लेकिन अगर सिर्फ IDE को efficiently इस्तेमाल करना ही लक्ष्य हो, तो Neovim setup पर इतना समय लगाना थोड़ा inefficient नहीं है?

    • Expreg(treesitter expand region) मुझे combobulate की याद दिलाता है (हालाँकि मैंने अभी इसे इस्तेमाल नहीं किया, लेकिन अच्छा लगता है)। फिर भी Expreg कहीं ज़्यादा simple और lightweight लगता है

    • मैं पुराने Emacs users के अनुभव सच में जानना चाहता हूँ। Helix/Vim की तुलना में यह कैसा है, यह जानने की उत्सुकता है। जो लोग पहली बार Helix/Vim इस्तेमाल करते हैं, वे अक्सर कहते हैं कि यह अच्छा है, लेकिन ऐसा लगता है कि वे लंबे समय तक Emacs इस्तेमाल करने की असली ताकत को नहीं जानते। सच तो यह है कि Vim-style keys या modes आजकल के editors में ज्यादा अच्छी तरह integrate होते हैं, लेकिन जब मैंने खुद इस्तेमाल किया तो मेरी उंगलियाँ अभ्यस्त होने तक टिके रहने का धैर्य नहीं था। किसी असली hardcore Emacs user का migration अनुभव सुनना चाहता हूँ

  • मैं Emacs → VS Code → Helix के रास्ते आया हूँ। अभी तक मेरी कोशिश यही रही है कि जितना हो सके मौजूदा keybindings सीखूँ और settings को लगभग छुए बिना प्रभावी ढंग से इस्तेमाल करूँ। Helix जो कुछ कर सकता है वह सब याद रखना मुश्किल था, इसलिए मैंने keys प्रिंट करके desk पर रखने के लिए एक deskmat बना लिया। असल में प्रिंट करके इस्तेमाल करने पर ही पता चलेगा कि कितना मददगार है। मेरा deskmat यहाँ देखा जा सकता है

    • जानना चाहूँगा कि आपने Emacs कितने समय तक इस्तेमाल किया

  • पिछले 10 सालों से Emacs मेरा मुख्य editor है, और उससे पहले मैं Sublime Text इस्तेमाल करता था। साधारण file editing या remote server पर कभी-कभी Vim इस्तेमाल कर लेता हूँ, लेकिन सिर्फ Vim पर पूरी तरह निर्भर होने की ज़रूरत महसूस नहीं हुई। Emacs में मैंने अपने modules और functions बनाकर बिल्कुल अपनी ज़रूरत के हिसाब से environment तैयार किया था। पिछले महीने Helix आज़माया, और शुरुआत करना हैरान करने वाली तरह से simple था। basic इस्तेमाल—movement, search, paste, buffer/window switching—भी जल्दी adapt हो गया। Helix का इतिहास मुझे ज्यादा नहीं पता, लेकिन इसकी design बहुत शानदार है। global search खास तौर पर अच्छा है, lsp integration बिल्कुल ठीक बैठती है, और speed वाकई तेज है। यह एहसास कि defaults बहुत consistently और उपयोगी ढंग से चुने गए हैं, बेहद सुखद है। आगे और अभ्यस्त होने के लिए इसे लगातार इस्तेमाल करने का इरादा है। मेरा default editor अभी भी Emacs है, लेकिन Helix इतना तेज है कि coding editor के तौर पर यह मेरा main editor बन सकता है

  • मैं अभी Helix पहली बार इस्तेमाल कर रहा हूँ, और दो कमियाँ बहुत स्पष्ट लगती हैं

    • modal editing इसकी core है, लेकिन Vim में आप अपनी existing muscle memory लगभग हर जगह वैसे ही इस्तेमाल कर सकते हैं (Vim mode लगभग हर जगह मिलता है, Vimium जैसे extensions भी बहुत हैं, और ssh environment हो तो लगभग हमेशा Vim मिलता है)
    • Helix simplicity को target करता है, इसलिए terminal integration नहीं है, और plugin extensibility भी ज्यादा नहीं है (lint functionality भी सिर्फ lsp-based है), तो ऐसा लगता है कि editor के ऊपर अलग setup बनाना पड़ेगा, जो एक limitation है (tmux वगैरह की ज़रूरत पड़ती है) मैं कमियों की आलोचना नहीं कर रहा, बस जानना चाहता हूँ कि इन बातों की भरपाई करने वाली इसकी ताकतें क्या हैं

    • मुझे समझ नहीं आता कि LSP कमी क्यों है। ऐसा लगता है कि LSP अलग process में चलता है, जो plugin sandboxing के लिहाज से तो अच्छा ही होना चाहिए। हो सकता है कि व्यवहार में यह traditional editor plugins से भी बेहतर काम करे। tmux integration की कमी भी मुझे महसूस नहीं हुई, क्योंकि मैं Emacs मुख्य रूप से इस्तेमाल करता हूँ लेकिन internal terminal लगभग कभी नहीं चलाता। और अगर बस muscle memory को migrate करना हो, तो Rust में बना तेज editor अपने आप में काफी persuasive है

    • लोग कहते हैं कि Vim motions muscle memory की तरह सीखे जा सकते हैं और फिर हर जगह इस्तेमाल होते हैं, लेकिन वास्तव में बहुत कम developers हैं जो plugin/config के बिना बिलकुल plain Vim environment ही चाहते हैं। ज्यादातर लोग अपना finely tuned setup और features चाहते हैं। अपवाद शायद वही लोग हैं जो सचमुच कई मशीनों पर ssh से जाते हैं और जिन्हें default editor environment चाहिए। आपने Helix की simplicity और plugin limitations का ज़िक्र किया, लेकिन Helix मूल रूप से all-in-one editor बनना चाहता था, जिसे community ने नहीं चाहा, इसलिए plugin system पर काम चल रहा है। main release में शामिल नहीं है, लेकिन अलग branch में कई plugins पहले से बने और इस्तेमाल हो रहे हैं। मुझे लगता है कि plugin system पर्याप्त stable होने तक release टालना सही फैसला है। Helix की सबसे बड़ी ताकत यह है कि उसने vi/vim/neovim में बचे हुए असुविधाजनक UX को सुधारा है। यानी workflow का क्रम बदलकर commit से पहले बदले हुए content को आसानी से देखा जा सकता है, जिससे unintended side effects कम होते हैं

  • इस स्तर की configuration हो तो शायद सीधा vim इस्तेमाल करना बेहतर लगेगा। आप Helix के अंदर vim features को दोबारा बना रहे हैं, और Helix खुद भी अंदर से कई dependencies रखता है (बस nvim की तरह सतह पर नहीं दिखाता)। मेरा vim8 setup 8 साल से भी ज़्यादा समय से simple बना हुआ है। vim8 इस्तेमाल करने की वजह यह है कि LTS distributions में यही version bundled आता है। सिर्फ एक plugin auto-load होता है (vim-tmux-navigator, जिससे vim splits और tmux panes के बीच आसानी से जाया जा सकता है), उसका code मैंने review किया है और update भी नहीं करता। दो "optional" plugins vim के built-in package manager से ज़रूरत पड़ने पर :packadd! के साथ चालू करता हूँ। सिर्फ ale(lsp, diagnostics, save पर auto format) और vim-fugitive(git integration) इस्तेमाल करता हूँ। ale की कोई dependency नहीं है। vim-fugitive एक बार install कर लो, फिर बस इस्तेमाल करो। plugins auto-load न करने की वजह यह है कि vim का सामान्य उपयोग तेज editing के लिए होता है, और लंबे projects में ही git/lsp चालू करता हूँ। बेकार plugins को लादने की ज़रूरत नहीं है

    • मुझे भी modern Neovim पसंद है, इसलिए मैं इस समस्या को हल करने के लिए एक Python package बना रहा हूँ (खासकर उन लोगों के लिए जो पहले से Python ecosystem में हैं या uv, pipx इस्तेमाल करते हैं)। uv tool install binwheels-neovim या pipx install binwheels-neovim से latest Neovim install किया जा सकता है, और यह Windows, mac, Linux पर तुरंत काम करता है। यह package official Neovim releases को wrap करता है और uv या pipx के ज़रिए OS/architecture के हिसाब से binary लाता है। Linux के मामले में official release से पुरानी GLIBC support की ज़रूरत होती है, इसलिए उसके लिए अलग build देकर उपलब्ध कराया जाता है। संबंधित जानकारी PyPI, Github main, build log में है

    • Helix में nvim+plugins की तुलना में supply-chain attack का surface area बेहद छोटा है। Helix एक ही source के तहत manage होता है, इसलिए हर plugin के अलग vendor वाले nvim की तुलना में काफी सुरक्षित है। Helix की releases धीमे और सावधानी से होती हैं, ताकि vulnerability आने पर भी बड़ा नुकसान न हो

    • Helix का editing model बेहतर है

  • अगर Helix इस्तेमाल करते हुए TUI चाहिए, तो neovim की जगह Helix क्यों चुनना चाहिए, यह समझना चाहता हूँ। Helix के defaults मुझे पसंद हैं, लेकिन एक बिंदु के बाद जब कुछ बदलना पड़ता है तो यह धीरे-धीरे ज्यादा झंझट वाला लगने लगता है। और अगर Helix से 'complete IDE experience' चाहिए, तो फिर Zed, VSC, या JetBrains IDE इस्तेमाल न करने की वजह भी साफ नहीं लगती। मुझे अगर simple चीज चाहिए तो nvim इस्तेमाल करता हूँ, और ज्यादा features चाहिए हों तो WebStorm खोल लेता हूँ, या कोई colleague कुछ ढूँढ़ना चाहता हो तो उसके साथ वही इस्तेमाल कर लेता हूँ

    • low-spec machine पर ssh से काम करते समय Helix लगभग तुरंत शुरू हो जाता है। वही चीज nvim में बनाओ तो धीमा हो जाता है, और config/plugin updates का maintenance cost बढ़ जाता है। और मुझे Rust आती है, इसलिए bug fixes में योगदान भी कर सकता हूँ। C family languages मुझे नहीं आतीं, इसलिए open source projects में मैं उन्हीं को prefer करता हूँ जो मेरी जानी हुई भाषा में लिखे हों। मैं 12 साल तक n/vim ही इस्तेमाल करता रहा और पिछले 2 साल में Helix पर आया हूँ, एक hobby coder के तौर पर। सच कहूँ तो nvim की कुछ चीजें अब भी याद आती हैं और कुछ वहाँ ज्यादा natural लगती हैं, लेकिन Helix सच में ‘instant-on’ है, और वही आराम सारी कमी पर भारी पड़ता है

    • पिछले कुछ वर्षों में मैंने neovim, helix, emacs, nano सबको कुछ समय तक इस्तेमाल किया है, और out-of-the-box experience के मामले में Helix बहुत आगे है। defaults वाकई बेहतरीन हैं, और context-based help तथा hints भी शानदार हैं, इसलिए अक्सर इस्तेमाल होने वाले commands भूल भी जाऊँ तो चलता है, और कम इस्तेमाल होने वाली चीजें भी आसानी से मिल जाती हैं। मेरे दिमाग में Helix का command order vim की तुलना में ज्यादा natural बैठता है। nvim/spacemacs जैसे modern editors में plugins/configuration की entry barrier बहुत ऊँची है। plugin ecosystem की वजह से Helix ऐसे काम भले न कर पाए जो वे कर सकते हैं (जैसे emacs में किसी भी Lisp भाषा को IDE की तरह इस्तेमाल करना, जबकि Helix में REPL लोड नहीं हो सकता), लेकिन उसके बदले editor ही नहीं, ढेर सारे plugins भी सीखने पड़ते हैं, और search करने पर answers version/combination के हिसाब से बदलते रहते हैं, जिससे भ्रम होता है। नया setup बनाते समय आखिरकार या तो किसी और की recommendation पर भरोसा करना पड़ता है, या खुद इस्तेमाल करके सीखने में अतिरिक्त समय लगता है। Helix नया project है, इसलिए उस पर पुराने फैसलों का बोझ नहीं है, और यह modern development patterns के अनुरूप निर्णय और defaults चुन सकता है। यह perfect नहीं है, लेकिन अगर कोई TUI beginner है और अभी तुरंत इस्तेमाल करने लायक, बिना configuration के आसान शुरुआत चाहता है, तो मैं Helix की सिफारिश करूँगा

    • hx शुरू होने में भी तेज है, चलने में भी तेज, और दिखने में भी अच्छा है। defaults से मैं काफी संतुष्ट हूँ, इसलिए बस हल्के बदलाव किए हैं। Emacs/Neovim की तरह endless improvement loop में फँसे रहने के बजाय hx में अंत दिखाई देता है। TUI remote server पर भी अच्छी तरह काम करता है, इसलिए mac, linux, server हर जगह मैं लगभग एक जैसा environment इस्तेमाल करता हूँ (दूसरे editors में भी संभव है, लेकिन hx यह अच्छे से support करता है)। मुझे जिन lsp की ज़रूरत है वे सभी ठीक से चलते हैं, और languages.toml configuration थोड़ी झंझट वाली थी, लेकिन बाकी editors में settings भी ऐसी ही लगती थीं

    • मुझे simple configuration और selection-first editing model पसंद है। इस विषय में संदर्भ यहाँ है। Vim के साथ कठिनाई महसूस करने वाले लोगों से बात करके मुझे लगा कि मैं मूल रूप से Helix जैसे 'पहले selection' model का अभ्यस्त था। Vim में जैसे target text दिखे बिना operation चलता है (यानी command देने के बाद असर का दायरा दिखता है), उस पर adapt करना मुश्किल था

    • editor चुनना उतना rational decision नहीं होता, जितना कि व्यक्तिगत पसंद, freshness, या मज़ा जैसे psychological factors का मामला होता है

  • :reset-diff-change command के बारे में मुझे पहली बार पता चला। मैं अब तक git में सिर्फ checkout -p इस्तेमाल करता था, लेकिन Helix के अंदर सीधे यह करना कहीं ज्यादा सुविधाजनक है

  • मैंने Helix इस्तेमाल किया, मेहनत से adapt किया, और अब मैं इसे अच्छी तरह चला सकता हूँ। लेकिन आखिर में मुझे महसूस हुआ कि यह 'उल्टा workflow' सीखने और implement करने में आसान तो है, मगर वास्तविक उपयोग में मेरी speed घटा देता है। इसलिए मैं वापस Vim, और फिर Zed(Vim mode) पर लौट गया

  • आज पहली बार Helix इस्तेमाल किया, और यह सच में बहुत अच्छी तरह designed editor है। लेकिन y2$, dw जैसे Vim के तेज shortcuts न होना थोड़ा खला

    • असल में shortcuts नहीं गायब हैं, बस y2$ को 2xy, और dw को wd की तरह लिखना होता है

  • Helix में खाली line समेत current line delete करने का तरीका अभी तक नहीं मिला। xd non-empty line पर एक line delete करता है, लेकिन line खाली हो तो दो lines एक साथ मिट जाती हैं

    • x current line select करता है, और अगर पहले से selected हो तो अगली line तक expand करता है। X selection को line boundaries तक expand करता है (line-wise selection)। X इस्तेमाल करें

    • खाली line पर बस d इस्तेमाल करें

    • यह चुपचाप काफ़ी असुविधाजनक है। मैं भी एक trivial fork चला रहा हूँ जिसमें empty line पर x का behavior अलग कर दिया है। विस्तार से यह PR देखें