Bad NEWS, Emacs
Emacs के register feature में एक विवादास्पद बदलाव—जिसमें एक अतिरिक्त confirmation step जोड़ा गया और दशकों पुराने keyboard workflows बदले गए—ने लंबे समय से उपयोग करने वालों में तीखी प्रतिक्रियाएँ पैदा की हैं। आलोचकों का कहना है कि muscle memory तोड़ना और शुरू में पुराने व्यवहार को बहाल करने का सरल तरीका न देना backward compatibility तथा Emacs की अत्यधिक customizability की भावना के प्रति उपेक्षा दिखाता है, जबकि अन्य का तर्क है कि master एक development branch है और नए users के लिए UX improvements वैध लक्ष्य हैं। यह बहस project governance, स्थापित interfaces को कब और कैसे तोड़ना स्वीकार्य है, और क्या ऐसे बदलाव हमेशा optional या opt-in होने चाहिए, जैसे व्यापक प्रश्नों तक फैल गई है.
क्या बदला और यह क्यों महत्वपूर्ण है
- यह बदलाव Emacs के “registers” (उन्नत multiple-clipboard / position फ़ीचर) को प्रभावित करता है, सामान्य copy/paste को नहीं।
- नए व्यवहार में एक minibuffer UI बीच में आता है जो registers दिखाता है और पुष्टि के लिए एक अतिरिक्त
RETकी आवश्यकता होती है। - आलोचकों का कहना है कि इससे एक तेज़, home-row, muscle-memory ऑपरेशन एक modal, धीमे ऑपरेशन में बदल जाता है, जो प्रति मिनट कई बार इस्तेमाल होता है।
- कई उपमाएँ दी गईं: जैसे हर
Ctrl-C/paste के बाद confirmation dialog मजबूर करना या किसी संगीतकार के instrument में latency जोड़ना।
उपयोगकर्ताओं और workflows पर प्रभाव
- registers के भारी उपयोगकर्ता टूट चुकी muscle memory, टूटे हुए macros, और बढ़े हुए cognitive load की रिपोर्ट करते हैं।
- कुछ लोग ज़ोर देते हैं कि प्रति-क्रिया छोटे विलंब workflows में बहुत बुरी तरह जुड़ जाते हैं, जो दिन में सैकड़ों बार इस्तेमाल होते हैं।
- अन्य लोग कहते हैं कि registers niche हैं; कई लंबे समय के उपयोगकर्ता इन्हें मुश्किल से ही इस्तेमाल करते हैं और इस टकराव को बढ़ा-चढ़ाकर बताया गया मानते हैं।
- thread में non-Emacs उपयोगकर्ता Vim की उपमाएँ देते हैं और सहमत हैं कि ऐसा बदलाव उनके editors में भी विघटनकारी होगा।
Configurability और fork की आवश्यकता
- एक पक्ष: Emacs में “everything is Lisp” है, इसलिए उपयोगकर्ता या packages आसानी से पुराने व्यवहार को बहाल कर सकते हैं; hard fork को राजनीतिक या ego-चालित माना जाता है।
- दूसरा पक्ष: core behavior पर monkey-patching करना व्यवहार में एक private fork बनाए रखने जैसा ही है और maintenance का बोझ उपयोगकर्ताओं पर डालता है।
- पुराने व्यवहार को बहाल करने के लिए options/toggles पर काम जारी है; कुछ पहले के प्रस्ताव इसलिए अस्वीकार किए गए क्योंकि वे अन्य नई सुविधाएँ भी हटा देते थे।
विकास प्रक्रिया और project governance
- चिंता यह है कि लंबे समय से मौजूद व्यवहार के लिए एक breaking UX बदलाव बहुत कम developers के बीच चर्चा के बाद
masterपर आ गया। - कुछ लोगों का तर्क है कि dev branch ठीक इसी तरह काम करने के लिए है: merge करो, फिर feedback के आधार पर release से पहले refine या revert करो।
- अन्य लोग “fiat” निर्णयों, backward compatibility के प्रति कम सम्मान, और revert करने की धीमी इच्छा का पैटर्न देखते हैं।
- कई commenters नोट करते हैं कि article की framing बहुत एकतरफ़ा है; mailing-list threads में अधिक nuance और सक्रिय iteration दिखाई देती है।
व्यापक design philosophy और “new vs old” users
- यह बहस कि Emacs को defaults newcomers के लिए optimize करने चाहिए (discoverability, safety) या power users के लिए (speed, stability)।
- कई लोग कहते हैं कि दशकों पुराने keybindings को तोड़ना दुर्लभ होना चाहिए, शुरुआत में opt-in होना चाहिए, और हमेशा एक स्पष्ट setting से revertible होना चाहिए।
- कुछ इसे एक व्यापक प्रवृत्ति का प्रतीक मानते हैं: UX “improvements” जो कई software projects में muscle memory का सम्मान नहीं करतीं।