बुरी खबर, Emacs
(eshelyaron.com)- यह Emacs 30 की registers सुविधा में बदलावों की आलोचना करने वाला लेख था, लेकिन फिलहाल सार्वजनिक बॉडी से मूल लेख हटा दिया गया है
- मूल लेख ने हालिया Emacs development की अत्यधिक आलोचनात्मक चर्चा की थी और संबंधित व्यक्तियों के प्रति असभ्य होने के कारण इसे हटाया गया
- हटाई गई सामग्री देखने के लिए केवल लेखक की वेबसाइट के Git log को देखने का निर्देश बचा है
- बची हुई मुख्य बात यह है कि लेखक ने रोज़मर्रा के इस्तेमाल के लिए Emacs की थोड़ी अलग branch इस्तेमाल करनी शुरू की है
- मौजूदा सार्वजनिक बॉडी से Emacs 30 registers सुविधा के ठोस बदलावों या तकनीकी मुद्दों को समझना मुश्किल है
हटाया गया Emacs 30 आलोचना लेख
- मूल लेख Emacs 30 की registers सुविधा में उन बदलावों पर था जिन्हें लेखक ने खराब माना था
- सार्वजनिक बॉडी में मूल लेख को हटाने का कारण बचा है: उसने हालिया Emacs development की अत्यधिक आलोचना की थी और संबंधित लोगों के प्रति असभ्य था
- यह भी हटाने की पृष्ठभूमि के रूप में बताया गया है कि उसे पिछले blog posts की तुलना में कहीं अधिक ध्यान मिला था
फिलहाल उपलब्ध जानकारी
- अगर आप हटाया गया लेख ज़रूर पढ़ना चाहते हैं, तो इस website का Git log देख सकते हैं
- लेखक ने बताया है कि उन्होंने रोज़मर्रा के इस्तेमाल के लिए Emacs की थोड़ी अलग branch इस्तेमाल करनी शुरू की है
- मौजूदा सार्वजनिक बॉडी में Emacs 30 registers सुविधा में बदलाव की ठोस समस्याएँ, उदाहरण या patch की जानकारी शामिल नहीं है
1 टिप्पणियां
Hacker News की राय
Emacs की development branch में, चाहे जानबूझकर हो या नहीं, compatibility तोड़ने वाला बदलाव आ गया और कुछ users ने चिंता जताई, फिर भी इसे तुरंत revert करने के तरीके से आगे नहीं बढ़ा गया।
फ़ायदे-नुकसान पर चर्चा करना, कई solutions को implement और improve करना, और फिर कोई बीच का रास्ता ढूंढ़ना ज़रूरी है। Users ने चिंता जताए अभी सिर्फ 3 दिन हुए हैं, इसलिए यह मानना मुश्किल है कि यह प्रक्रिया अब तक पूरी हो जानी चाहिए थी।
Eli के हालिया जवाब का आशय भी यही था: “शुरुआती चर्चा में शामिल दो लोगों को नया behavior पुराने behavior से कहीं ज़्यादा उचित लगा, लेकिन अब विरोधी राय भी आ गई है, इसलिए behavior पर आगे चर्चा की जा सकती है और उसके बाद default पर बात हो सकती है।”
मुझे लगता है कि Emacs के development तरीके में गंभीर समस्याएँ हैं, लेकिन यह भी समस्या है कि users आम दिनों में emacs-devel के ज़िद्दी लोगों को दोष देते हैं और फिर जब कोई ऐसा बदलाव आता है जो उन्हें पसंद नहीं, तो ऐसे बर्ताव करते हैं जैसे दुनिया खत्म हो गई हो। इससे maintainers रक्षात्मक हो जाते हैं।
mail thread पढ़ने पर यह “घमंड” से ज़्यादा एक मज़बूत असहमति लगती है, और consensus बनने में समय लगना स्वाभाविक है। सिर्फ इसलिए कि कोई आपकी नज़र से तुरंत पीछे नहीं हटता, उसे सार्वजनिक रूप से “घमंडी” कहना और ऐसे लोगों की भीड़ जुटाने की कोशिश करना जिन्होंने thread पढ़ा भी नहीं होगा, harassment के काफ़ी क़रीब लगता है।
यह कहना भी ईमानदार नहीं है कि बदलाव को optional बनाने वाला patch अनदेखा कर दिया गया। वह patch सिर्फ optionality नहीं जोड़ता था, उसने दूसरे बदलाव भी हटा दिए थे, इसलिए उसे reject किया गया; और इस तरह सारी ज़िम्मेदारी एक व्यक्ति पर डालना भी स्वीकार करना कठिन है।
अगर users ने प्रतिक्रिया न दी होती, तो बताए गए process के हिसाब से संभवतः वही मूल बदलाव जस का तस चला जाता जिसका वे विरोध कर रहे थे। clojure-mode में भी rms ने लंबे समय से Clojure community के एक contributor का नाम लेकर rewrite करने की कोशिश की थी; लोगों ने mailing list पर विरोध किया तो वह रुका, लेकिन उन्हीं लोगों से कहा गया कि वे बढ़ा-चढ़ाकर बोल रहे हैं। इसलिए “अतिरंजना” वाली आलोचना ज़्यादा सार्थक नहीं लगती।
व्यापक community से चर्चा किए बिना user workflow तोड़ने वाला feature main branch में डालेंगे, तो लोगों का नाराज़ होना स्वाभाविक है। इसी तरह के merges से पुराने tools community का समर्थन खो देते हैं।
अगर compatibility तोड़ने वाले बदलाव को तुरंत revert करने पर गंभीरता से विचार नहीं किया जाता, तो यह संकेत होगा कि Emacs developers अब backward compatibility को पहले जितना महत्व नहीं देते, और इसका मतलब होगा कि वे अपने पुराने users के एक बड़े हिस्से को छोड़ रहे हैं।
https://www.murilopereira.com/the-values-of-emacs-the-neovim...
core values मायने रखते हैं। Emacs maintainers ने core values का उल्लंघन किया है, और community का असहज होना जायज़ है।
user workflow तोड़ते हुए इसे optional भी नहीं बनाया गया, opt-in तो दूर, इसे बंद तक नहीं किया जा सकता था; यह user experience के प्रति लापरवाह अनदेखी जैसा दिखता है।
मैंने जो समझा उसका सार यह है कि हाल ही में Emacs में copy से थोड़ा अधिक सामान्य register व्यवहार को बदलने वाला एक commit स्वीकार किया गया है
अब Emacs एक minibuffer खोलकर दिखाता है कि क्या होने वाला है, और बदलाव को मंज़ूर करने के लिए Enter या उसके समकक्ष input देना पड़ता है। मूल पोस्ट के लेखक के मुताबिक यह डिफ़ॉल्ट व्यवहार बदल देता है, इसे आसानी से setting से बंद भी न किया जा सके, और इस पर पर्याप्त चर्चा भी नहीं हुई, इसलिए यह भयानक compatibility break है
Vim से तुलना करें तो जैसे आप मौजूदा line को
dregister में copy करने के लिए\"dyyटाइप करें, और उसके बाद scratch buffer खुल जाए जो text और buffer दिखाए, फिर उसे बंद करने के लिए key input मांगे। Register समझने वाले सामान्य Vim user को यह भयानक लगेगा, लेकिन visual mode में copy करने वालों की तरह कुछ लोग “क्या copy होने जा रहा है यह साफ़ दिखाने” वाले व्यवहार को पसंद भी कर सकते हैंबाकी लेख में कहा गया है कि मूल लेखक ने इस पर चर्चा शुरू करने की कोशिश की, लेकिन commit लेखक Thierry ने उसे रोका, और निहित रूप से बाकी Emacs developer community भी कुछ हद तक ज़िम्मेदार है
मैंने दशकों तक Emacs इस्तेमाल किया है, लेकिन registers में बहुत गहराई तक नहीं गया; निजी तौर पर copy के लिए kill/yank और जटिल editing के लिए multiple cursors या one-off keyboard macros का उपयोग किया है। फिर भी Emacs में ऐसे लोगों के लिए कई वैकल्पिक advanced editing features हैं जो muscle memory पर निर्भर रहना चाहते हैं
इसमें confirmation key input जोड़ना अजीब है। यह किसी electronic piano पर “अजीब chord confirm pedal” जोड़ने जैसा है, यानी तेज़ और जटिल input action पर एक अतिरिक्त step चढ़ाना
Emacs में शानदार undo है, इसलिए “क्या आप register d की सामग्री paste करना चाहते हैं?” पूछने से बेहतर है बस paste कर दिया जाए, और अगर user ने गलत चुना हो तो वह undo कर ले
इसलिए यहां compatibility तोड़ना अजीब है, और अगर इसे बंद करने का तरीका भी न हो तो बहुत से users का नाराज़ होना स्वाभाविक है। Emacs आधुनिक GUI परंपराओं से भी पुराना tool है, इसलिए वह vscodium जितना नए users के लिए परिचित नहीं हो सकता; ऐसे में power users को जितना हो सके उतना अच्छी तरह serve करने वाली दलील भी वाजिब है
kill-ring-save, यानी defaultM-w, प्रभावित नहीं होता; केवल अधिक advanced feature register save बदल रहा हैregister clipboard, यानी kill ring, का superset नहीं है
और जो लोग कहते हैं कि यह बदलाव configurable नहीं होगा, वे शायद Emacs की customizability को ठीक से नहीं जानते। “setting” तो सिर्फ़ सुविधा है; चाहें तो code को जड़ से बदल सकते हैं। यह Emacs के Elisp हिस्से का मामला है, इसलिए जैसा भी merge हो, कुछ ही मिनटों में व्यवहार बदलने वाला package आ जाएगा। इसके लिए fork की ज़रूरत नहीं, और यहां fork की बात करना ज़्यादा से ज़्यादा एक performative gesture जैसा है
अगर इसे revert नहीं किया गया, तो उम्मीद है कोई macro snippet मिल जाए जो मेरी जगह यह अतिरिक्त key input संभाल ले। Emacs में साधारण कामों के लिए भी पहले से बहुत key inputs लगते हैं, और मैं इतना expert नहीं कि इस बदलाव के लिए macro खुद बना सकूँ
लगता है यह मामला तब शुरू हुआ जब Thierry ने register behavior में कुछ समस्याएँ देखीं और उन्हें ठीक करने की कोशिश की
सबसे महत्वपूर्ण defect यह था कि
C-x r SPCसेsave-to-registerदबाने के बाद अगली जो भी key दबाई जाती, उसी key के register में text save हो जाता था। खास तौर पर Emacs की universal cancel keyC-gभी यहां काम नहीं करती थी, और text या position^gनाम के register में save हो जाता था। अगरjump-to-registerयाinsert-registerगलती से दब जाए, तब भीC-gवगैरह से cancel नहीं किया जा सकता था; register चुनना ही पड़ता थादूसरी बात, register में text, position, या empty value में से कुछ भी हो सकता है।
jump-to-registerकेवल position वाले register पर काम करता है, औरinsert-registertext की अपेक्षा करता है। Emacs command चलाते समय non-empty registers का preview देता है, लेकिन वह अंतर नहीं बताता था; जैसे string वाले register भीjump-to-registerके candidate के रूप में दिख जाते थेThierry इन समस्याओं और code review feedback को ठीक करना चाहते थे, और reviewers ने माना कि अतिरिक्त interaction होने पर भी यह महत्वपूर्ण बदलाव है। उनका मानना था कि सामान्य register selection के बाद
RETदबाने की ज़रूरत, या^gजैसे अजीब register में save करने के लिए अतिरिक्त key लगना, यानी compatibility break, मिलने वाले फ़ायदे के मुकाबले स्वीकार्य हैमूल लेखक ने नए और पुराने व्यवहार के बीच switch मांगा और जवाब में patch भेजने को कहा गया, लेकिन जो patch उसने भेजा उसने ऊपर बताए गए सभी सुधार वापस कर दिए और पूरी तरह अलग feature “non-empty register overwrite confirmation” को flag आधारित रूप में लागू किया। Thierry ने उसे apply करके देखा और संक्षिप्त feedback दिया, जिस पर लेखक ने लगभग यह कहकर जवाब दिया कि “ऐसी चीज़ की ज़रूरत नहीं”
बाद में जैसे-जैसे और लोगों ने feature इस्तेमाल किया, Thierry और शुरुआती reviewers का यह विश्वास ग़लत साबित हुआ कि इस breaking change का असर छोटा होगा, और Thierry ने नया behavior बनाए रखते हुए पुराना flow भी अनुमति देने वाला flag बनाना शुरू किया। खास तौर पर अतिरिक्त
RETहटाना मुख्य उद्देश्य नहीं बल्कि लगभग side effect थाकुल मिलाकर प्रक्रिया काफ़ी अच्छी तरह काम करती दिखती है, और संदर्भ को नज़रअंदाज़ करके “अगर कुछ मोटे तौर पर काम कर रहा है तो उसे किसी भी तरह बदला नहीं जाना चाहिए” जैसी anti-hacker मानसिकता से चर्चा को धकेलने की कोशिश मूल लेखक की तरफ़ ज़्यादा दिखती है
dyyका मतलब मौजूदा line delete होना अपेक्षित लगतालेकिन शायद वही इस बात का सबूत है कि वह beginner है
इस mailing list thread को देखें तो लगता है कि उस व्यवहार को वापस करने वाला एक option आ सकता है: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t
लगता है यह option मूल पोस्ट आने से पहले ही उल्लेखित हो चुका था, हालांकि संभव है लेखक ने उसे न देखा हो। इससे समस्या हल होती दिखती है, लेकिन शायद मैं कुछ चूक रहा हूँ
संशोधन: नीचे ginko के जवाब को देखें तो लगता है कि अभी भी RETURN key input चाहिए होगा
RETकी ज़रूरत पड़ती दिखती हैhttps://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
register-use-previewsइस व्यवहार का toggle लगता हैहालांकि
neverपर set करने के बाद भी कुछ workflows में confirmation आने वाले bug का ज़िक्र है। अगर यह सचमुच option है, तो ज़्यादातर चिंताएँ दूर हो जानी चाहिएEmacs में muscle memory को सबसे अहम प्राथमिकताओं में रखना चाहिए
क्योंकि जमा हुई muscle memory टूट गई थी। शांत होने से पहले काफ़ी खतरनाक तरह के ख़याल भी आए थे। यह मामूली लग सकता है, लेकिन “muscle memory के साथ धोखा” जैसे अपराध पर प्रतिक्रिया “fork you” तक क्यों पहुँचती है, यह समझ में आता है
यही बात Google Maps या iOS पर भी उतनी ही लागू होती है जितनी Emacs पर
muscle memory हर छोटे interaction पर आँखों से जाँच किए बिना software को “देखे बिना”, लगभग अर्ध-स्वचालित तरीके से चलाने देती है। दुख की बात है कि desktop software में keyboard operation को लगातार ज़्यादा झंझटभरा या बिल्कुल असंभव बनाने की प्रवृत्ति है
rant अच्छा है, लेकिन जिस feature की बात हो रही है वह क्या है, यह न बताना तर्क को कमज़ोर करता है
Emacs registers बहुत पुराना abstraction हैं। register में अलग clipboard की तरह value रखी और निकाली जा सकती है, और
[a-zA-Z0-9]से जुड़े 62 core ASCII symbols पर आधारित होने की वजह से यह flexible और तेज़ keyboard interface देता है। register से keyboard macros चलाने जैसी दिलचस्प चीज़ें भी की जा सकती हैं। कुछ लोग इन्हें बहुत इस्तेमाल करते हैं, लेकिन मैं व्यक्तिगत रूप से नहीं करतालेखक इसलिए नाराज़ है क्योंकि default binding बदल गई है, और पहले जो काम पूरी तरह keyboard और home row से हो जाता था, उसके बीच अब एक modal UI आ गया है। शिकायत वाजिब लगती है, और अगर मेरी muscle memory में बैठी कोई चीज़ ऐसे बदल दी जाए तो मैं भी चिढ़ जाता
अगर selection और paste के बीच हर बार confirm करने वाला modal dialog आ जाए, और पुराने behavior पर लौटने की setting भी न हो, तो गुस्सा आना तय है। पुराने behavior को option के रूप में लागू करना चाहिए। सचमुच, इसके लिए बस कुछ lines of code चाहिए
C-aregister access को तोड़ देता हैमैं किसी को जानता हूँ जो locations के लिए character और text के लिए
C-चरित्रका इस्तेमाल करता है। किसी के लिए यह बहुत niche use case हो सकता है, लेकिन ऐसे लोग बहुत नाराज़ होंगेhttps://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/ में Eli कहता है, “विरोध आया है, इसलिए अभी यह चर्चा जारी है कि behavior क्या होना चाहिए, और निष्कर्ष के बाद ही default पर बात की जा सकती है”
मूल लेखक की व्याख्या अच्छी नहीं है। जो users स्थिरता चाहते हैं उन्हें release branch पर रहना चाहिए या master के किसी commit को pin करना चाहिए
development branch का इस्तेमाल जारी features के development के लिए होता है, और ऐसे features को polish होने में समय लग सकता है। अगर आप master follow करते हैं, तो compatibility तोड़ने वाले बदलाव बार-बार मिलेंगे, और workflow टूटने पर पुराने commit पर लौटना आपको आना चाहिए। बेहतर विकल्प release पर बने रहना है
Emacs की असली ताकत यह है कि वह बेहद customizable platform है; अगर किसी feature का behavior पसंद नहीं है, तो आप Lisp की कुछ lines लिखकर उसे खुद बदल सकते हैं
किसी obscure feature change की वजह से पूरे project को fork करना बिल्कुल समझदारी नहीं है। मैं लगभग 1981 से, जब यह TECO macros में implement होता था, Emacs इस्तेमाल कर रहा हूँ, लेकिन registers का उपयोग नहीं करता
नहीं तो platform बदलते ही हर किसी को हर बार अपनी सारी custom settings फिर से लिखनी या ठीक करनी पड़ेगी
अगर यह patch ऐसे ही रह जाता है और कोई सचमुच ठीक पुराना behavior चाहता है, तो उसे practically अपने local Emacs repository पर revert patch लगाकर उसके ऊपर अपने बदलाव रखने होंगे। और जब भी upstream Emacs बदलेगा, नए बदलाव लेने के लिए rebase करना होगा
वही तो private fork है। हमेशा के लिए fork होकर हमेशा rebase करते रहना
या फिर आप किसी तरह monkey patch से shipped files की जगह या बाद में अपनी file load करके function redefine कर सकते हैं, लेकिन वह भी एक तरह का fork ही है। आपको अपनी सामग्री किसी project में कहीं रखनी होगी, और changes की वजह से monkey patch टूटे तो उसे ठीक करने के लिए तैयार रहना होगा
मुझे Emacs छोड़े 20 साल हो चुके हैं, लेकिन यह समझ सकता हूँ कि यह बदलाव काफ़ी disruptive है
जो बात समझ नहीं आती वह यह है कि “kitchen sink तक सब शामिल है” कहकर गर्व करने वाला Emacs पुराने behavior पर लौटने का option क्यों नहीं जोड़ता
उस patch में flag तो जोड़ा गया था, लेकिन उसके साथ बाकी improvements भी हट जाती थीं
इस लेख का tone काफ़ी “neckbeard” जैसा है। यह कोई Holy Sepulchre की हिलाई न जा सकने वाली सीढ़ी नहीं, बल्कि ऐसा बेहद obscure feature है जिसे शायद सिर्फ़ तीन nerd इस्तेमाल करते हैं
कोई unpaid maintainer आपसे पहले पूछे बिना इसमें हल्का बदलाव कर दे, तो ज़रूरी नहीं कि उसने “master तोड़ दिया” हो। और यहाँ बात stable version या tagged release की नहीं, बल्कि master की हो रही है
जाहिर है, एकमात्र संभव समाधान यही है कि एक और Emacs fork या reimplementation की कोशिश की जाए
इस बार तो यह निश्चित ही सफल होगा, और बाकी की तरह पूरी तरह असंबद्ध चीज़ बनकर नहीं रह जाएगा
हालाँकि fork main project को बातचीत की मेज़ तक खींच लाता है या नहीं, यह बहुत मायने नहीं रखता। मूल लेखक के पास अपने local repository में उस patch को लंबे समय तक बनाए रखने की क्षमता और इच्छा है। fork को पूरा करने के लिए बस इतना बाकी है कि वह उस local repository को public कर दे
हो सकता है कि यह mainline maintainers को मनाने की कोशिश भर हो