Helix Editor 25.07

 (helix-editor.com)
1 पॉइंट द्वारा GN⁺ 2025-07-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Helix 25.07 में मुख्य कंपोनेंट्स के प्रतिस्थापन और कई नई सुविधाओं की जोड़ शामिल है
  • फाइल एक्सप्लोरर, LSP document color display, कमांड मोड सुधार आदि के कारण उपयोगिता और workflow में बड़ा सुधार हुआ है
  • syntax highlighting और query optimization के लिए नया crate Tree-house पेश किया गया है
  • Tree-house injection और local handling क्षमताओं के साथ performance और maintainability को काफी मजबूत करता है
  • आगे चलकर अधिक व्यापक multi-language experience और speed सुधारों की नींव तैयार हुई है

Helix 25.07 के प्रमुख अपडेट

Helix 25.07 रिलीज़ में लंबे समय से प्रतीक्षित मुख्य फीचर प्रतिस्थापन और कई नई सुविधाएँ शामिल हैं। इस संस्करण में 195 contributors ने भाग लिया। Helix एक modal text editor है, जिसमें multiple selections, LSP, Tree-sitter, और experimental DAP support मौजूद है।

नई प्रमुख सुविधाएँ

फाइल एक्सप्लोरर

  • 25.07 में <space>e से इस्तेमाल किया जा सकने वाला file explorer फीचर जोड़ा गया है
  • यह एक्सप्लोरर telescope जैसी UI प्रदान करता है
  • डायरेक्टरी के भीतर hierarchical structure को नेविगेट करना आसान हो जाता है, और large projects को खोजते समय अधिक सटीक नियंत्रण मिलता है

LSP document color display

  • अब Helix LSP server से document color information मांगकर RGB color ranges को inline दिखाता है
  • उदाहरण के लिए tailwindcss-language-server, vscode-css-language-server आदि से color information लेकर कोड के भीतर सीधे color boxes को देखा जा सकता है

कमांड मोड (:) फीचर सुधार

  • command parsing और autocomplete code के पूर्ण rewrite से bugs ठीक हुए हैं और usability बेहतर हुई है
  • :write परिवार के commands में --no-format flag जैसी flag support जोड़ी गई है
  • कमांड के भीतर variable/value expansion (%{variable_name}, %sh{명령어} आदि) फीचर और autocomplete जोड़ा गया है
  • जटिल input values को संभालने के लिए इसे extensible parser structure में बदला गया है, जिससे भविष्य में command विस्तार आसान होगा

Tree-house: Tree-sitter integration की नई संरचना

Tree-sitter क्या है

  • Tree-sitter तेज़ और error-tolerant parsers बनाने और उपयोग करने वाला framework है
  • grammar DSL से parser rules लिखे जाते हैं, और editor/tool के भीतर syntax trees बनाए और उपयोग किए जाते हैं
  • उदाहरण के तौर पर यह GitHub के code navigation और highlighting, code server के spell-check, diff tools आदि में उपयोग होता है
  • Tree-sitter queries का उपयोग subtree pattern matching और syntax node capture के लिए किया जाता है

Helix का पुराना Tree-sitter integration और उसकी समस्याएँ

  • Helix के शुरुआती दौर में आधिकारिक Rust binding (tree-sitter crate) और tree-sitter-highlight highlighter का उपयोग किया गया
  • tree-sitter-highlight non-incremental है, इसलिए पूरे document को हर बार फिर से parse करना पड़ता था, जिससे performance गिरती थी और resources व्यर्थ होते थे
  • Helix ने इसे सुधारने के लिए अपना highlighter fork किया, लेकिन वह धीरे-धीरे जटिल होता गया और maintainability कठिन हो गई

Tree-house की शुरुआत और उसके फायदे

  • Tree-house अलग parsing/query structure, साफ-सुथरे code, पुराने chronic bugs के अंत, और future-oriented architecture (जैसे parallel parsing) पर केंद्रित है
  • इसकी मुख्य ताकत injection को मज़बूती से संभालना है

Injection: कई भाषाओं/लेयर्स का समर्थन

  • Injection का मतलब है कि, उदाहरण के लिए, Markdown के भीतर Rust code block आने पर उस हिस्से को अलग से Rust के रूप में parse किया जाता है
  • जटिल मामलों (जैसे Rust comments के भीतर Markdown, और उसके code blocks के भीतर फिर Rust) को भी tree structure से layers प्रबंधित करके सटीक रूप से सपोर्ट किया जाता है

Incremental injection

  • केवल जिन layers में वास्तविक बदलाव हुआ है, उन्हीं को तेज़ी से फिर से parse और query किया जाता है, जिससे काम की न्यूनतम इकाई ही उपयोग होती है
  • बहुत बड़े lists या nested structure वाले markdown documents में इसकी efficiency अधिकतम हो जाती है

Local variable highlighting (lcals)

  • functions के भीतर parameters जैसे local variables को declaration और reference scope में सटीक रूप से highlight किया जाता है
  • पहले यदि definition view के बाहर हो तो highlighting गायब हो जाती थी; Tree-house ने इस पुरानी समस्या को हल कर दिया है

Globalized injection support

  • Syntax type में injection layers की खोज और lookup logarithmic time में संभव है
  • TreeCursor, QueryIter जैसी APIs के जरिए पूरे injection layer पर एकसमान रूप से काम किया जा सकता है
  • HTML <script> के भीतर code, Markdown code blocks आदि में भाषाई सीमाओं के पार सुसंगत व्यवहार लागू करने की नींव तैयार हो गई है

समापन

  • Helix 25.07 ने file explorer, color inlay, command mode/parser improvements जैसी usability innovations के साथ-साथ Tree-house आधारित नई संरचना लाकर इसे अगली पीढ़ी के text editor के एक मजबूत दावेदार के रूप में उभारा है
  • विस्तृत अपडेट changelog में देखे जा सकते हैं
  • community/contribution में भागीदारी Matrix और GitHub repository के माध्यम से की जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2025-07-17
Hacker News राय

  • Helix वाकई शानदार है। फ़ाइल पिकर, syntax highlighting, linting जैसी कई सुविधाएँ बिना plugin इंस्टॉल किए या जटिल configuration के सीधे मिल जाती हैं, जबकि vim या neovim में आम तौर पर काफ़ी setup करना पड़ता है। मैं इसे इस्तेमाल करना चाहता हूँ, लेकिन सबसे बड़ा नुकसान यह है कि इसकी key bindings vim से अलग तरह से काम करती हैं। मेरे लिए परिचित x का cursor के नीचे वाले अक्षर को delete करना, या d का आगे command का इंतज़ार करना जैसे vim के पुराने और स्वाभाविक key behavior अगर वैसे के वैसे न हों, तो वह अनुभव उलझाने वाला और चिढ़ाने वाला लगता है। शायद बहुत से vim users भी इस हिस्से में ऐसा ही महसूस करेंगे, और आदत बदलना बहुत मुश्किल होता है। खासकर इसलिए कि vim लगभग हर जगह default रूप से मौजूद होता है, इसलिए उससे बाहर निकलना आसान नहीं। अच्छी बात यह है कि evil-helix नाम का Helix का एक soft fork Vim key bindings जोड़ देता है, इसलिए मेरी जैसी दिक्कत वाले लोगों को मैं इसे सुझाना चाहूँगा। साथ ही Helix और evil-helix Windows(cmd) पर भी rust इंस्टॉल किए बिना सिर्फ .exe डाउनलोड करके अच्छी तरह चल जाते हैं.

    • मेरे लिए समस्या यह नहीं है कि मैं कुछ नया सीखना नहीं चाहता, बल्कि यह है कि इन key bindings को मैं दूसरी जगह इस्तेमाल नहीं कर सकता। लगभग सभी online editors और workstations vim key bindings देते हैं, और Linux पर ssh से जुड़ो तो vim हमेशा मिलता है — यह बहुत अहम है। यह कुछ वैसा है जैसे QWERTY keyboard: भले ही उससे बेहतर layout हों, लेकिन लगभग हर environment में तुरंत ढल जाने वाली flexibility छोड़ना मुश्किल है.

    • नया tool सीखने में मुझे कोई दिक्कत नहीं है। मैंने Helix को काफ़ी इस्तेमाल किया, लेकिन noun-verb model मुझे उल्टा कम अच्छा लगा, और visual feedback भी code पढ़ते समय ध्यान भटकाने वाला लगा। vim में आख़िरी command दोहराना जैसे काम (. binding वगैरह) बड़ी आसानी से हो जाते हैं, लेकिन Helix में यह सुविधा छोड़नी पड़ती है। state management पर भी vim से ज़्यादा ध्यान देना पड़ता है; vim में बस फ़ाइल के भीतर अपनी मौजूदा जगह याद रखनी होती है, लेकिन Helix में यह भी सोचना पड़ता है कि मैं कहाँ था। मुझे default settings वाला, modal editing वाला, और ज़रूरत से ज़्यादा visual synchronization थोपने वाला editor नहीं चाहिए। बहुत ज़्यादा synchronization होने पर editing language के तौर पर उसका फ़ायदा कम हो जाता है। मैं editing से ज़्यादा दिलचस्प programming पर ध्यान देना चाहता हूँ; जो editor ज़्यादा concentration माँगे, वह editor के रूप में उतना अच्छा नहीं लगता.

    • vim(neovim) को लगभग 20 साल इस्तेमाल करने के बाद जब मैं helix पर गया, तो यह बिल्कुल भी मुश्किल नहीं था, और अब मैं इसे काफ़ी ज़्यादा पसंद करता हूँ। मैंने कुछ modal behavior बदले ज़रूर हैं, लेकिन helix की logic के साथ ही इस्तेमाल कर रहा हूँ। multi-selection या LSP जैसी सुविधाएँ built-in मिलती हैं, और multi-step input के दौरान कौन-कौन से actions संभव हैं, यह hints में दिखाने वाली मज़बूत help system इसका बड़ा फ़ायदा है। कभी-कभी plain vim इस्तेमाल करना पड़े तो भी, भले दिमाग़ की mapping बदल गई हो, basic commands याद रहते हैं और जल्दी adjust हो जाता हूँ.

    • Helix इस समय programmable configuration के लिए Scheme जोड़ रहा है। जब programmable features आ जाएँगे, तो अभी emacs में repeat/transient map, per-state tracking जैसी तरह-तरह की fine tuning भी संभव हो जाएगी। LLMs की क्रांति की वजह से 8वीं, 9वीं language भी आसानी से छू लेने वाली दुनिया में मुझे लगता है कि बारीक configuration वाले tools बाज़ार में और उभरेंगे.

    • vim key bindings ही एकमात्र वजह थीं कि मैं Helix इस्तेमाल नहीं करता था। अगर किसी external fork के ज़रिए vim support संभव है, तो Helix official भी चाहे तो इसे support कर सकता होगा — तो क्या वह जानबूझकर ऐसा नहीं कर रहा?

  • मुझे Helix बहुत पसंद है। जिन लोगों को vim ठीक से जँचा नहीं, या जिन्हें vim का concept अच्छा लगता है लेकिन उसमें आसानी से ढल नहीं पाए, उनके लिए इसे मैं ज़ोरदार recommendation दूँगा। पुराने vim-जैसे editors की तुलना में इसे सीखना और इस्तेमाल करना बहुत आसान लगा, और जो defaults built-in मिलते हैं वे बेहद practical हैं.

    • मुझे Helix बहुत पसंद है। सच कहूँ तो अगर इसमें mouse-based file explorer जैसी GUI वाली थोड़ी और सुविधा जुड़ जाए, तो मुझे लगता है यह vscode का मज़बूत प्रतिद्वंद्वी बन सकता है.

  • इतनी शानदार क्षमताओं वाला editor अब भी minimal बना हुआ है और बेकार के AI features पर ध्यान नहीं देता, यह देखकर अच्छा लगता है.

  • बधाई और शुभकामनाएँ, मैं चाहता हूँ कि Helix सफल हो, लेकिन यह मेरे लिए सही नहीं लगता। मैं Neovim इस्तेमाल करता हूँ और जो चाहता हूँ उसका लगभग सब कुछ वहाँ हो जाता है। फिर भी मैं पूरी तरह संतुष्ट नहीं हूँ। मेरे आदर्श editor में ये बातें होनी चाहिए:

    • modern codebase, पूरी तरह नया लिखा गया
    • Vim key bindings — यह muscle memory बहुत गहरी है, इसलिए मैं Vim style पर अड़ा हूँ; कोई यह कहे कि कुछ और बेहतर है, उससे फ़र्क नहीं पड़ता, मैं चाहता हूँ कि यह ठीक Vim की तरह काम करे
    • अच्छे defaults — Neovim में configuration बहुत ज़्यादा है और defaults हमेशा संतोषजनक नहीं लगते
    • Treesitter आधारित, और अगर WASM पर चल सके तो और अच्छा (Zed, नए Neovim की तरह)
    • extension system Lua में हो; JS या Scheme पसंद नहीं। आदर्श रूप से WASM modules के लिए ज़रूरी functions ही expose हों। plugin configuration के लिए non-Turing-complete config language चाहिए
    • TUI और optional GUI
    • built-in LSP, DAP, snippets, autocomplete, testing/debugging UI
    • Oil.nvim जैसा built-in filesystem view
    • Telescope/FZF-lua style built-in search
    • git integration, और magit/neogit जैसी git UI built-in हो तो स्वागत है
    • Flash.nvim style Treesitter आधारित AST manipulation और label jump built-in
    • macros और multi-cursor
    • optional cursor-based AI integration (Chat UI)

    • मैं भी Vim muscle memory को मानता हूँ, लेकिन मुझे लगता है कि बहुत से लोग इससे कुछ ज़्यादा ही चिपके रहते हैं। मैंने कई बार OS, editor, IDE बदले हैं, और बदलाव के शुरुआती कुछ दिन बेहद कुंठाजनक, गुस्सा दिलाने वाले होते हैं — ऐसा लगता है खेती ही कर लूँ — लेकिन वह समय बीतते ही हमेशा नई muscle memory बन जाती है। सिर्फ़ कुछ दिनों की असुविधा की वजह से software के बाकी इतने सारे फ़ायदों को छोड़ देना मुझे अफ़सोसजनक लगता है.

    • यह साफ़ नहीं है कि ऊपर बताए गए किन मानकों पर Helix कम पड़ता है। मेरी नज़र में तो Helix लगभग सब कुछ पूरा करता दिखता है.

    • requirements देखकर लगता है कि आप मूल रूप से Neovim ही चाहते हैं, बस Lua की जगह कोई दूसरी भाषा हो.

  • मुझे Helix बहुत पसंद है, बधाई। इसका default theme सुंदर है, defaults भी शानदार हैं, install करते ही तुरंत इस्तेमाल किया जा सकता है और कोई खास setup नहीं चाहिए। इसने पूरी तरह IDE की जगह नहीं ली, लेकिन मैंने vi का alias इसे बना दिया है और $EDITOR भी Helix पर सेट कर दिया है। CLI में जल्दी से edit या debug करना ho, तो मैं हमेशा Helix ही खोलता हूँ.

  • मुझे Helix सच में पसंद है और उससे लगाव भी था, लेकिन इसका undo behavior कुछ तार्किक नहीं लगा। कई बार यह एक साथ बहुत ज़्यादा चीज़ें undo कर देता था, जो अप्राकृतिक लगा। इसी वजह से मैंने सच में काम भी खोया है.

    • Undo को लेकर दो बातें मुझे परेशान करती थीं:

      • अगर undo की जाने वाली edit screen पर दिखाई नहीं दे रही हो, तो यह उस जगह jump तो सही से करता है, लेकिन उसी key press में undo भी कर देता है, जिससे भ्रम होता है। दूसरे editors में अगर content दिख नहीं रहा हो, तो वे सिर्फ़ jump करते हैं, undo नहीं। Helix में एक बार key दबाने के बाद यह देखना पड़ता है कि कुछ बदल भी गया या नहीं.
      • undo बहुत बड़े chunks में होता है। अगर insert mode में 30 मिनट तक typing करो, तो mode switch होने तक सब कुछ एक ही बार में undo हो जाता है। save points manually register करने पड़ते हैं। मैंने इसे ज़्यादा granular undo के लिए spacebar पर assign करने की कोशिश की, लेकिन इससे selection गायब हो जाने जैसे side effects हुए। मुझे कोई साफ़-सुथरा हल नहीं मिला। कुल मिलाकर Helix से मैं संतुष्ट हूँ, लेकिन undo की गहराई को सीधे हाथ से नियंत्रित करना पड़े, यह सच में खलता है.

    • Undo और "repeat last command" थोड़ा अजीब ज़रूर हैं, लेकिन बाकी features इतने अच्छे हैं कि मैं अब भी Helix को main editor की तरह इस्तेमाल करता हूँ। लेकिन जहाँ काम खोने की बात है, वहाँ क्या बाद में redo भी नहीं हो पाया था?

  • मैं चाहता हूँ कि Helix में "Kakoune mode" आए। काम पर Windows इस्तेमाल करने की वजह से Kakoune आदर्श नहीं है, इसलिए Helix लगभग परफ़ेक्ट लगा, लेकिन key bindings की रुकावट पार करना मुश्किल है। Helix की key binding philosophy, Kakoune की संक्षिप्तता की तुलना में, ज़्यादा verbose लगती है और यही बात खटकती है। साथ ही Helix की key binding configuration इतनी ताकतवर नहीं है कि Kakoune को ठीक से follow कर सके, यह भी अफ़सोस की बात है। मैं vim की inconsistency और illogical behavior से निराश होकर Kakoune पर गया था, और Helix इस मामले में एक कदम पीछे लगता है.

  • इसे "post modern" editor कहना मज़ेदार है। Fish shell के "shell for the 90s" के बाद यह दूसरा सबसे अच्छा मज़ाक लगता है। वीडियो में देखकर इसका TUI-based होना प्रभावशाली लगा, और उसमें थोड़ा Emacs TUI जैसा एहसास भी है.

  • Helix जैसी all-in-one completeness वाला एक vim-like editor सच में चाहिए। Neovim distributions में अलग-अलग हिस्से इतने ढीले तरीके से जुड़े होते हैं कि हमेशा कुछ न कुछ हल्की-सी असुविधा बनी रहती है। मुझे लगता है Vim interface को कुल मिलाकर फिर से redesign की ज़रूरत है, लेकिन action-object केंद्रित modal approach बनी रहनी चाहिए.

    • Evil-Helix शायद ऐसी ज़रूरत के काफ़ी करीब है। अभी भी इसमें काफ़ी खुरदुरापन दिखता है, लेकिन देखना चाहिए: https://github.com/usagi-flow/evil-helix

    • यह action-object modal approach क्या होती है?

  • Helix और इसी तरह के editors में syntax highlighting और code understanding features के बारे में विस्तृत विवरण प्रभावित करने वाला था। tree-sitter आधारित structure और features query language के लिए एकदम उपयुक्त लगते हैं, और symbol search या reference finding से आगे बढ़कर एक general-purpose query DSL की संभावना भी दिखती है। क्या ऐसी सुविधा पहले से कहीं मौजूद है?