@@html:<div class="metadata">@@Created on [{{{date}}}], last updated [{{{modification-time(%Y-%m-%d, t)}}}]@@html:</div>@@
-*NOTE:* the following contains several hyperboles that reflect my
-emotions, and should probably be taken with a grain of salt, or not at
-all. While I am intentionally expressing criticism, I most sincerely
-hope not to offend anyone.
-
-*NOTE2:* this +rant+ post got a lot more attention than I expected!
-Please note that the Emacs maintainers are working on addressing these
-issues. I can't say whether the outcome will work for me personally,
-but I am grateful for their continuous efforts. Thank you, and long
-live Emacs!
-
-.
-.
-.
-
-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, Emacs 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. [EDIT: There used to be another sentence here, but I
-removed it after seeing that this post spread, since it was unkind
-towards the Emacs maintainers and didn't really contribute anything to
-the point of this post.]
-
-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 an 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, the maintainers seem insistent
-not to budge, and Emacs 30 will thus likely suck.
-
-I find the willingness of the Emacs maintainers to entertain this bad
-behavior at the expense of user experience unacceptable. To me, this
-demonstrates disrespect for Emacs user preferences, and indeed their
-freedom.
-
-Personally, 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 (only) good
-changes 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
- # or
- git clone https://git.sr.ht/~eshel/emacs
-#+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.
+This was an excessively critical account of a recent development in
+Emacs. It got far more attention than my previous writings on this
+blog, and I've taken it down because it was unkind towards involved
+individuals.
+
+If you really want to read this rant, you can check the Git logs of
+this website. The gist is that I've started using a slightly
+divergent [[https://git.sr.ht/~eshel/emacs][branch]] of Emacs as my daily driver.
projects / esy-publish.git / commitdiff