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 (file)
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:<div class="metadata">@@Created on [{{{date}}}], last updated [{{{modification-time(%Y-%m-%d, t)}}}]@@html:</div>@@
+
+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.