- कोड की संरचना को सीधे बदलने वाला multi-cursor आधारित structural editor, जो syntax tree (AST) को केंद्र में रखकर काम करता है
- syntax node स्तर की interaction को सपोर्ट करता है, जिससे कोड लिखने की मंशा और वास्तविक editing action के बीच का अंतर कम होता है
- multi-cursor फीचर के साथ कई syntax nodes को एक साथ संशोधित या refactor किया जा सकता है, जिससे बड़े पैमाने पर editing की efficiency बढ़ती है
- mode-based editing तरीके को फिर से परिभाषित करता है, जिससे word, line, syntax node जैसी अलग-अलग इकाइयों में एकसमान तरीके से move करना संभव होता है
- कोड editing की accuracy और consistency को मजबूत करता है और developer productivity बढ़ाने वाला एक नया editing paradigm पेश करता है
Ki Editor का परिचय
- Ki Editor एक multi-cursor structural editor है, जो कोड की syntax structure को सीधे संभालने वाला editing environment प्रदान करता है
- पारंपरिक text-based editing से अलग, यह syntax tree (AST) के आधार पर code elements को manipulate करता है
- mouse या keyboard combinations के बिना syntax node स्तर पर सीधे editing संभव है
syntax node interaction
- First-class syntax node interaction फीचर के जरिए कोड की syntax structure को सीधे संभाला जाता है
- फोकस कोड लिखने की मंशा और वास्तविक editing action के बीच के अंतर को कम करने पर है
- mouse movement या जटिल key input के बिना syntax unit स्तर की manipulation की जाती है
multi-cursor फीचर
- Multiple cursors का उपयोग करके कई syntax nodes को एक साथ edit किया जा सकता है
- parallel syntax node manipulation से bulk editing और refactoring efficiency बेहतर होती है
- दोहराए जाने वाले code modification tasks को तेज़ी से निपटाया जा सकता है
mode-based editing की पुनर्परिभाषा
- Redefine modal editing फीचर के साथ selection modes को standardize किया गया है
- word, line, syntax node जैसी अलग-अलग इकाइयों में movement को एकसमान तरीके से सपोर्ट करता है
- मौजूदा mode-based editing की तुलना में flexibility और consistency को बेहतर बनाता है
महत्व
- Ki Editor syntax structure-केंद्रित editing अनुभव प्रदान करता है, जिससे कोड लिखने और संशोधित करने की accuracy बढ़ती है
- multi-cursor और syntax node manipulation को मिलाकर यह developer productivity बढ़ाने वाले code editing के एक नए approach का सुझाव देता है
1 टिप्पणियां
Hacker News की राय
“First-class syntactic selection” फीचर देखकर JetBrains IDE का अक्सर इस्तेमाल होने वाला Expand / Shrink Selection शॉर्टकट याद आ गया
Ctrl + W,Ctrl + Shift + Wकॉम्बिनेशन से चयन क्षेत्र को syntax unit के हिसाब से expand या shrink किया जा सकता हैइस फीचर की वजह से फ़ाइल के ‘text’ के साथ इंटरैक्ट करने के तरीके पर मेरा नज़रिया पूरी तरह बदल गया
VS Code और Zed में भी ऐसा मिलता-जुलता फीचर है, लेकिन वह थोड़ा ज़्यादा रफ़ तरीके से expand/shrink होता लगता है
JetBrains दस्तावेज़ लिंक
Cmd+Shift+V से stack clipboard खुलता है, जिसमें पुरानी copied entries खोजी या चुनी जा सकती हैं
Cmd+Shift+E recent locations की सूची दिखाता है, और Cmd+Shift+A action palette खोलता है जहाँ सभी commands को fuzzy search से ढूँढा जा सकता है
और Local History फीचर से Git से भी कहीं ज़्यादा बारीकी से file change history ट्रैक की जा सकती है
ऐसे फीचर आगे चलकर “search results buffer में सीधे edit” करने जैसी अवधारणा तक ले जाते हैं
incremental selectionसे यही फीचर इस्तेमाल किया जा सकता हैdouble-click से शब्द, triple-click से पूरे function arguments, और 4 बार क्लिक करने पर पूरा
f(a,r,g,s)चुनने जैसी क्लिक की संख्या के साथ syntax unit बढ़ने वाली संरचना थीआज भी उसकी muscle memory बनी हुई है
commit, diff और cherry-pick में भी Ctrl+W की तरह syntax unit के हिसाब से काम कराने का आइडिया आज़मा रहा हूँ
इससे जुड़ी बातें librdx project में संक्षेप में लिखी हैं
AST-aware editing से Lisp family languages की सुविधा याद आती है
Lisp में जो काम साधारण list manipulation से हो जाता है, JS में उसके लिए LSP या अलग parser चाहिए
वीकेंड पर Clojure इस्तेमाल करके TypeScript पर लौटो तो paredit commands सच में बहुत याद आती हैं
मैंने पहले syntax tree आधारित editor खुद बनाया था
text input करने के बजाय सिर्फ tree को manipulate किया जाता था, इसलिए syntactically गलत program का अस्तित्व ही नहीं हो सकता था
लेकिन इसे practically usable input method बनाना बहुत बड़ी चुनौती थी
अब उस समय का display hardware नहीं है, इसलिए चला नहीं सकता, लेकिन project description बचा हुआ है
नतीजतन कभी ग़ैर-स्वाभाविक रास्तों से जाना पड़ता है, या कई बार शुरुआत से फिर लिखना पड़ता है
यहाँ तक कि ऐसी संरचनाएँ भी संभव हैं जो valid तो हों लेकिन जिन तक पहुँचने का generation path ही मौजूद न हो
सिद्धांत के स्तर पर रोचक है, लेकिन व्यावहारिकता के लिहाज़ से यह बंद गली जैसा लगा
text-based interface की सार्वभौमिकता और सरलता को हराना मुश्किल है
dedicated editor, नया version control, ecosystem से कटाव जैसी वास्तविक सीमाएँ बहुत बड़ी हैं
इंसान tree units में नहीं सोचता, इसलिए सिर्फ syntactically सही state में रहकर coding करना बेहद घुटनभरा अनुभव था
आख़िरकार लचीली कठोरता देने वाले tools ही टिकते हैं, जैसे TypeScript की gradual typing
संबंधित सामग्री: simh, mame, VT11 code, दस्तावेज़
अभी यह general-purpose editor नहीं है, लेकिन tree selection range को expand करने की दिशा आशाजनक लगती है
Pantograph लिंक
यह एक ऐसे parser system पर बना है जो अपूर्ण लेकिन valid trees को संभाल सकता है
<//>जैसी gap representation के ज़रिए अधूरे syntax को सुरक्षित तरीके से हैंडल किया जा सकता हैउदाहरण:
2 + ·को<BinaryExpression>tree के रूप में parse किया जा सकता हैरुचि हो तो Discord community में इस पर चर्चा चल रही है
मैं AST editing का आदी नहीं हूँ
function arguments या arglist के लिए text objects जैसा कुछ ही इस्तेमाल करता हूँ
LSP फीचर्स में भी बस go to definition और rename तक ही सीमित हूँ
कुल मिलाकर editor skills और निखारने की प्रेरणा मिली
आप code जैसी ही syntax में pattern लिख सकते हैं और transformation सामने देख सकते हैं
उदाहरण के लिए
ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang tsकी तरह optional chaining transformation किया जा सकता हैmetavariables
$X,$Aवगैरह एक ही node match होने को enforce करती हैंअभी AI coding agents ऐसे patterns का उपयोग अच्छी तरह नहीं कर पाते, लेकिन tool खुद बहुत मज़बूत है
ज़्यादातर बार syntax node unit पर select करके delete/copy/replace करना ही काफ़ी होता है
मैं बड़े पैमाने के refactoring अक्सर नहीं करता, इसलिए इसे सीखना ज़रूरी नहीं लगा
लेकिन बड़े service पर काम करने वाले developers की राय बिल्कुल अलग हो सकती है
Elixir में macro लिखना सीखते हुए बहुत समझ मिली, और Lisp भी इसी संदर्भ में आता है
भाषाएँ अलग रास्ते अपनाएँ, लेकिन मंज़िल आख़िरकार एक ही लगती है
मेरे हिसाब से editors का वर्गीकरण कुछ ऐसा है
Ki तीसरी श्रेणी में आता है, और मैं ऐसे projects पर लगातार नज़र रखता हूँ
UI nodes सामान्य text जैसे दिखते हैं, लेकिन असल में tree structure हैं
शुरुआती feedback देना चाहें तो profile में दिए email पर संपर्क करें
AST editing की कठिनाई discoverability है
चीज़ें स्क्रीन पर दिखती तो हैं, लेकिन कई बार उस node का नाम पता नहीं होता
इसलिए मैं ऐसा plugin सोच रहा हूँ जो cursor के आसपास रंगों से हर scope को visualize करे
“अगले function पर जाओ” के बजाय “अगले नीले रंग पर जाओ” जैसे ढंग से सोचने का तरीका होगा
d mदबाने पर इस समय दिख रहे सभी syntax nodes के labels दिखते हैं और वहीं से सीधे jump किया जा सकता हैजैसे वर्तमान node के अंदरूनी या बाहरी हिस्से को चुनने जैसी operations काम की होती हैं
मैंने VSCode के लिए Ki integration बनाया था
उसके बाद ज़्यादा योगदान नहीं दे पाया, इसका अफ़सोस है, लेकिन इस तरह की मूलभूत tool innovation बहुत महत्वपूर्ण लगती है
Ki VSCode extension लिंक
उदाहरण देखने से पहले मैं ठीक से नहीं समझ पाया था,
लेकिन “First-class syntactic modification” में comma अपने-आप add/remove होते देख कर प्रभावित हुआ
implementation logic भी उल्टा काफ़ी सरल लगती है
अब Zed में भी Ki integration या AST-based rewrite आज़माने का मन है
Ki repository का code देखकर समझा जा सकता है
मैं इसे जल्द खुद इस्तेमाल करके देखूँगा
इसका keyboard layout independent होना मुझे पसंद आया
Emacs की “everything is an editable buffer” philosophy से प्रेरणा लेना भी दिलचस्प है
बेशक हर editor में trade-offs बहुत होते हैं, इसलिए खुद आज़माने पर ही ठीक से पता चलेगा
Neovim शानदार है, लेकिन editing model की सीमाएँ हैं
अगर यह पूरी तरह replaceable architecture होता, तो शायद Helix या Ki की ज़रूरत ही न पड़ती
Dvorak keyboard पर चलाया तो mapping पूरी तरह टूट गई
जब software यह मान ले कि वह user से ज़्यादा समझदार है, तब user को बेबस होने का एहसास होने लगता है
जैसा कि उम्मीद थी, Emacs में यह पहले से मौजूद है
combobulate package इसका उदाहरण है
M-k से nodes delete किए जा सकते हैं, या tree-sitter queries से सीधे search/edit किया जा सकता है
integration पहले से बहुत बढ़िया है, लेकिन AST-dedicated editor हो तो UX को और आगे ले जाने की गुंजाइश है
यह फीचर Helix workflow में सचमुच बहुत अच्छी तरह फिट बैठता है
मौजूदा move → action pattern में जैसे आख़िरी piece आकर जुड़ गया हो