From: Eshel Yaron Date: Sun, 10 Dec 2023 11:59:51 +0000 (+0100) Subject: New post about bad Emacs NEWS X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=70e41438e6ebb347e576ac060f6fadaa20e78b95;p=esy-publish.git New post about bad Emacs NEWS --- diff --git a/source/posts/2023-12-10-bad-news.org b/source/posts/2023-12-10-bad-news.org new file mode 100644 index 0000000..8c9bb46 --- /dev/null +++ b/source/posts/2023-12-10-bad-news.org @@ -0,0 +1,148 @@ +#+TITLE: Bad NEWS, Emacs +#+SUBTITLE: Troubles registered in Emacs 30 +#+DESCRIPTION: Post by Eshel Yaron about changes for the worse in Emacs 30 registers feature +#+KEYWORDS: emacs +#+DATE: 2023-12-10 + +@@html:
@@Created on [{{{date}}}], last updated [{{{modification-time(%Y-%m-%d, t)}}}]@@html:
@@ + +The [[note:emacs][Emacs]] master branch is broken---for good, it seems. Emacs +maintainers accepted a heavy-handed, harmful change, disregarding +concerns voiced by multiple users and developers. I've created a +fixed, and improved, fork. I'll be using and developing this fork, +and you're welcome to join. + +Let's take a step back. What is the Emacs master branch? That's +essentially the development version of Emacs, and what will soon +become Emacs version 30. Many Emacs hackers and enthusiasts track the +master branch to enjoy all of the latest developments and +improvements. Thanks to the tireless work of the Emacs maintainers in +scrutinizing incoming patches, the Emacs master branch has been very +stable in recent years. But a few weeks ago, Emacs master users got a +very unpleasant surprise. + +#+begin_src diff +commit 589e6ae1fb983bfba42f20906773555037246e45 +Author: Thierry Volpiatto +Date: Sun Nov 19 20:42:56 2023 +0100 + +Improve register-preview (bug#66394) + + A minibuffer is used now instead of read-key. + ... +#+end_src + +This commit crippled all user interaction with Emacs registers, +turning commands such as ~C-x r s~, once smooth and frictionless, into +a cumbersome and painful mess. Concretely, instead of just typing the +key for the register you want to operate on, you now get a fully blown +minibuffer for inserting a single key. This is nonsensical in various +ways, but most staggering is probably the fact that you now need to +confirm your register selection by pressing another ~RET~, effectively +doubling the work you have to do for the simplest task of specifying a +single character. + +Emacs registers (used to) provide a perfect UX. Silky smooth, really. +But no more, not in GNU Emacs 30. It's gone, without as much as a +=NEWS= entry to inform the unwary user about this regression. + +Surely, it's not too late to revert one bad change, right? That's +what I thought, unfortunately the Emacs maintainers seem bent on +dismissing the community's outcry in a desperate and misguided attempt +to save face. + +In fact, the core problems with this change were brought up already in +the first technical [[https://yhetil.org/emacs/87sf67qqmp.fsf@web.de/][comment]] regarding this patch proposal, from +Michael Heerdegen: + +#+begin_quote +If your version is accepted, I would vote for an option to get the old +behavior back. Your intended behavior is safer but requires more keys +(at least confirmation with RET). Some people might prefer the old +way. +#+end_quote + +Well, duh! If you're gonna change long standing Emacs behavior, it +better be optional and backward compatible, people have been using +this thing for decades, after all. Hmm apparently, the patch author, +Thierry, doesn't see it that way: + +#+begin_quote +There is only RET as additional key and it is a good thing IMO as it +let the time to user to see what he is doing. +#+end_quote + +This rather arrogant statement, and the approach that underlies it, +led us to where we are today. After some further discussion, [[note:eli-zaretskii][Eli +Zaretskii]] applied this patch to Emacs master. I'm not sure he +understood the breaking nature of this change when he did that, which +I think might be even more disconcerting. + +Soon after, Bastien Guerry chimed in, saying: + +#+begin_quote +I use registers ~100 times a day, so enhancements here are very +welcome, thanks! + +I wonder about this [change], though. It badly hinders my usual flow, +where I do remember what registers I use and like to store new ones +quickly. +#+end_quote + +Sounds like a clear and honest testimony from an esteemed community +member. But wait, no, Thierry doesn't think so, he thinks it's all +for the better and his change is all right. At this point I got +somewhat involved, and seconded Bastien's request to restore the +previous, perfectly good behavior, at least optionally. Thierry +wasn't willing to fix this damage, so Eli asked me to help out: + +#+begin_quote +So maybe a better way forward is for someone, perhaps you Eshel, to +add whatever is needed to provide optionally the previous behavior? + +Would you like to work on that? +#+end_quote + +Easy enough. I crafted and [[https://yhetil.org/emacs/m1wmtvnfpn.fsf@dazzs-mbp.home/][posted]] a couple of patches that add some +bells and whistles from Thierry's patch in an optional and compatible +manner. It's really not that hard to make no harm in this case. But +my work was disregarded just as well, sadly. Thierry didn't like how +I reverted his change to use the minibuffer for reading a single key, +which is exactly the root cause of the problems I tried to fix---and +in fact I did fix it, just not in Emacs master, but in my new fork. + +Since then, [[https://yhetil.org/emacs/CA+Nei8MfEw_iDj3Xjbzop+7n-oqNp1jSJcweOgEQMKUkB3mifQ@mail.gmail.com/][another bug report]] came in from a Emacs master branch user +that suffered from one of the consequences of this change (a specific +regression that I spelled out days before, but was ignored, for some +reason), and several users reached out to the Emacs development in +request to restore the previous behavior in an ongoing thread titled +[[https://yhetil.org/emacs/CAFgA-y2wUR0tGRk+RkUGn2TF2YoMyf3B=+78TGyDZP5+Ew2uyA@mail.gmail.com/]["Please, Restore Previous Behavior for jump-to-register"]]. +Astonishingly, Eli and Thierry won't seem to budge, and Emacs 30 will +thus likely suck. + +I find the willingness of the Emacs maintainers to entertain this bad +behavior (of both a rouge developer and of Emacs itself) at the +expense of user experience, unacceptable. This demonstrates clear +disrespect for Emacs user preferences, and indeed their freedom. + +For me, this freedom is the number one reason for using Emacs, so I +obviously won't use an Emacs that forces on me weird breaking changes. +For that reason I've created a new Emacs branch, the "main" branch, +which was born from the master branch before this registers fiasco. + +If these changes will be reverted before Emacs 30, I'll surely +consider switching back to building Emacs from the upstream master +branch. But in the meantime, and for the foreseeable future, I'll be +keeping my main branch up to date by cherry picking good change (only) +from the master branch. And of course, I also improve it with +developments of my own. + +If you're interested, feel free to checkout my main branch from here: + +#+begin_src shell + git clone git://git.eshelyaron.com/emacs.git +#+end_src + +I'll be happy to coordinate and incorporate other's work. [[mailto:me@eshelyaron.com][Let me know]] +if you have any suggestions, thoughts, or nice harmless patches that I +should try out.