]> git.eshelyaron.com Git - esy-publish.git/commitdiff
Update bad NEWS post
authorEshel Yaron <me@eshelyaron.com>
Mon, 11 Dec 2023 10:06:45 +0000 (11:06 +0100)
committerEshel Yaron <me@eshelyaron.com>
Mon, 11 Dec 2023 10:06:45 +0000 (11:06 +0100)
source/posts/2023-12-10-bad-news.org

index 53c1d19f0c9a4f4837219d1b1d74c429b290e47a..85f047d0c7ea0118300fdfb951aed0d7ae128e07 100644 (file)
@@ -6,6 +6,21 @@
 
 @@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
@@ -47,9 +62,10 @@ 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 an unwarranted and misguided
-attempt to save face.
+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
@@ -111,24 +127,25 @@ 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.
+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 (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.
+behavior at the expense of user experience unacceptable.  To me, this
+demonstrates 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.
+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
@@ -141,6 +158,8 @@ 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]]