Bad NEWS, Emacs

When a breaking change is made on Emacs&#x27; development branch, whether intentionally or not, and some users voice concerns about that change, then the change isn&#x27;t reverted the minute those concerns are raised. The pros and cons are discussed, different solutions are implemented and improved, and finally a compromise is found.<p>Users raising their concern started three days ago. That&#x27;s not enough for this process to have concluded already.<p>Here&#x27;s a recent message by Eli (and the message he is responding to).<p><pre><code> &gt; I&#x27;m hoping the old behavior stays the default and the new behaviour &gt; is what users can opt in with a variable. &gt; &gt; If that is what normally happens for much less disruptive changes, &gt; why isn&#x27;t it happening for this deep impacting one? Because the original discussion of these changes, between two people who were interested and involved, indicated that the new behavior makes much more sense than the old one. Now, that others chimed in with the opposite views, we are still discussing what should be the behavior, and once that is concluded, we can talk about the defaults. </code></pre> So I think this has been blown way out of proportion. IMO there are some serious issues in how Emacs is developed. I don&#x27;t have a solution but I think that us users&#x2F;package-maintainers thinking to ourselves &quot;gee there sure are a lot of stubborn people on emacs-devel, what&#x27;s wrong with them?&quot; and then the second a change is made that we strongly disagree with, we start behaving like the world is ending, that might be a problem. This is how maintainers get defensive (you might have noticed that in the projects that <i>you</i> maintain).

I&#x27;ll summarize my understanding.<p>A commit that changes how copying (actually &quot;registers&quot;, which is a bit more general than copying) works in emacs was recently accepted. Now emacs opens up a minibuffer that shows what is happening, requiring one to <i>accept</i> the change by hitting <i>enter</i> or equivalent. The OP thinks this is a terrible, breaking change as it changes default behavior (and possibly without the possibility of easily configuring this away). Further, this happened without much discussion.<p>Let&#x27;s state a vim analogy. If I want to copy the current line into my `d` register, I can type `&quot;dyy`. This proposal would do something like, after typing `&quot;dyy`, open up a scratch buffer that tells the user the text and the buffer, requiring a keystroke to close. This is terrible for people who understand registers (the typical vim user). But I acknowledge that sometimes I don&#x27;t copy the intended text into registers and have to try again. I also know many vim people who only yank from visual mode, which has a similar show-explicitly-what-is-being-copied behavior.<p>The rest of this article is a description of how the OP tried to raise discussion, but the commit-author, Thierry, shot it down. Implicitly the rest of the emacs dev community is at fault too.

Reviewing the mailing list threads on this, it looks like there will be an option to revert this behaviour: <a href="https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;87h6kr9817.fsf@posteo.net&#x2F;#t" rel="nofollow noreferrer">https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;87h6kr9817.fsf@posteo.net&#x2F;#t</a><p>It seems like this option was mentioned before the original post was published, but perhaps the author didn&#x27;t see this? I assume this would fix the issue, but I may be missing something.<p>--<p>EDIT: it looks like this will still require a RETURN keypress, based on the reply from ginko below.

Muscle memory should be elevated to a first class concern when it comes to emacs.

It&#x27;s a good rant, but it probably doesn&#x27;t help its case that it doesn&#x27;t stop to explain what the feature it&#x27;s talking about actually is. Emacs registers are a really, really old abstraction. Registers are like separate clipboards, you can put stuff there and pull it out. And there are 62 of them (each associated with a core ASCII symbol: [a-zA-Z0-9]), giving you a lot of flexibilty and a very quick keyboard interface for acting on&#x2F;with them. And you can even do fun stuff like execute a keyboard macro out of a register. Some people use them heavily. I don&#x27;t.<p>Anyway the author is peeved that they changed the default bindings such that there&#x27;s a modal UI in the way of what used to be a fully-keyboard&#x2F;home-row operation. It sounds like a reasonable complaint; I&#x27;d be annoyed too if they changed something that lived in my muscle memory like this kind of feature does.

This is a bad take by the author; users wanting stability should be on the release branch, or pin commits on master. It should be expected that the development branch is used to develop in-progress features. Sometimes these take a while to hammer out. If you follow master, you will have frequent breaking changes and should be comfortable reverting to a previous commit when theres something breaking your workflow. Better yet, stay on a release.

Seriously, WTF?<p>The whole point of Emacs is that it is a radically customizable platform, and if you don&#x27;t like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense.<p>Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don&#x27;t use registers.

It’s been 20 years since I left Emacs, but I understand that this change is pretty disruptive. What I do not understand is why Emacs that prides itself in being the “kitchen sink” did not add an option to revert to the old behaviour.

The tone of this author... Very... &quot;neckbeard&quot;-esque. This is an incredibly obscure feature only 3 nerds use, not the the Immovable Ladder of the Church of the Holy Sepulcher. The fact that some unpaid maintainer changed it slightly without consulting you first does not necessarily constitute &quot;breaking master.&quot; It&#x27;s master we&#x27;re talking about, not stable or a tagged release. Good god.

Obviously the only possible solution is to attempt another fork&#x2F;reimplementation of emacs. This one will definitely win and not be totally irrelevant like all the others.

So, what&#x27;s the &quot;other side&#x27;s&quot; argument in this? Usually these opinionated changes come with some level-headed reasoning behind the changes. Or maybe not?

I think a more effective approach to getting this reverted would be to actually describe the problem for people who don’t know what registers are, and to include the reasoning for the change, so that people can actually weigh the pros and cons and form an opinion.<p>I also think you can leave out the names of individuals, you can discuss the idea on its merits without their identities being involved. All it accomplishes is demonizing people who donate their time to the project. Already this thread has people saying stuff like “I don’t like this person.”

This is really polemically overstating the case, but at least it links to the mailing list threads where you can see what&#x27;s actually going on. Not that anyone will click them.

I am a Vim guy. Can someone explain what exactly is broken?

The &quot;maintainer&quot; is Thierry Volpiatto, mostly known as author of helm, a completion framework.

At the end of the day though, it&#x27;s emacs.<p>In lisp alone, you can get the old behavior back if you want it.<p>I think usability decisions like this are one of the harder things to decide by committee in an open source project because they are, at the end of the day, questions of taste. And people can have conflicting and equally valid tastes. Here, a swap is being made between editing speed and accuracy, with the one perhaps having the better claim for purely historical reasons (but if you let historical reasons dictate design, you end up with faster horses not cars).<p>Me personally, I&#x27;m a committed emacs user and I don&#x27;t have skin in this game. If I don&#x27;t like the new UI, I&#x27;ll just add the necessary code to swap it out for the old UI.

It’s a slippery slope<p><i>”it looks like you are trying to create a buffer that is not attached to a file. If that is actually what you intended please confirm with RET so that the buffer can be created but keep in mind that. . .”</i>

I have been using emacs since probably 94. This change, without a toggle from userspace to disable it is a kick in the pants. I will follow your fork until (if) they come around.

Looks like the Emacs developer community needs a Linus to talk some sense into these Mauros<p>Referring of course to <a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2012&#x2F;12&#x2F;23&#x2F;75" rel="nofollow noreferrer">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2012&#x2F;12&#x2F;23&#x2F;75</a>

it indeed looks like a bad idea. New behavior should be optional, old behavior should be default so that it does not affects existing workflow of users. I am heavy emacs user but i use stable release, i hope this change does not makes into the stable release.

I don’t fully understand the nature&#x2F;impact of the change but this conflict seems so minor to me. Like, people on both sides display the same level of entitlement but for different reasons, and they all think they have their are “right”. Hum, no, for outsiders you all appear stubborn and lacking ability to compromise. “Oh my gosh, I’ll have to press 1 extra key now, this project is doomed!”, “no no no, this little change is the hallmark of security, it should be mandatory for every user”. Come on…

I was sure to read “the forces of vim have invaded our headquarters and now hold our CEO hostage.”

It seems like Emacs has a fairly toxic development process.<p>Arguing that because something has been committed to the development branch it can&#x27;t be reverted, is a terrible policy.

OpenSource working as intended, no?

It may be an unpopular approach, but I&#x27;m a fan of Linus&#x27;s &quot;you must never break user-space&#x2F;UX.&quot; Some changes might be trivial for you or even an &quot;improvement&quot; (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any other key because &quot;it makes things nicer&quot; is clearly a bug.<p>I&#x27;m also not fond of Emacs&#x27;s many subtle UX changes in the last couple of years. Enabling eldoc by default, changing &quot;blink-matching-paren&quot; default value... For each new Emacs release, I have to revisit my init.el and revert to the old behavior (thank you, elisp!), because suddenly things start to pop out or jump around. I get it; this is maybe to please the newer&#x2F;younger crowd who are usually &quot;in transit&quot; - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with &quot;a big bag of odor.&quot;<p>Thanks to elisp, you can bend Emacs any way you want, but don&#x27;t change default behavior just because &quot;it looks nice to me&quot;.

I am sorry but this whole post seems like gaslighting. Looks like maintainers welcomed a patch bringing the old behaviour behind a flag [1]. Eshel Yaron then writes &quot;Sure. I&#x27;m attaching two patches&quot;, while doing the exact opposite of what was asked, namely undoing the commit that has already landed on the main branch and introducing merely parts [2] of the new behaviour behind the flag.<p>It&#x27;s totally fine to disagree with people. Agreeing with people while doing the complete opposite, is quite unacceptable, in my opinion.<p>[1]: <a href="https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;837clv6sga.fsf@gnu.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;837clv6sga.fsf@gnu.org&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;87r0k2pgq6.fsf@posteo.net&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;yhetil.org&#x2F;emacs&#x2F;87r0k2pgq6.fsf@posteo.net&#x2F;</a>

Maybe let&#x27;s keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs&#x27; features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There&#x27;s still discussion if overwriting registers should prompt for confirmation (which it didn&#x27;t use to do). Let&#x27;s wait how that one turns out. I fail to see why one would need to write a long blog post and maintain a fork because of something like this... maybe just wait it out a bit and let people voice their opinions, it takes a bit of time...

This thread is mostly &quot;I don&#x27;t use this feature of Emacs (or Emacs at all) therefore this isn&#x27;t a real problem, so stop complaining.&quot; Poor to see.<p>I&#x27;d rather people who do regularly use the feature weigh in on how they feel about its new behavior.

Is it just me, or is Emacs much more drama-prone, compared to Vim, VSCode, or any other text editor?

&gt; Since then, 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 “Please, Restore Previous Behavior for jump-to-register”. Astonishingly, Eli and Thierry won’t seem to budge, and Emacs 30 will thus likely suck.<p>Seriously, this is kind of funny. I use emacs for like two decades now and I knew about jump-to-register but never actively used it. But yes - emacs 30 will be bad because of this change. Barely useable anymore. This guys in their mailinglist have... very specific problems.<p>You heard it first here. Emacs 30 will suck.<p>Also; <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1172&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;xkcd.com&#x2F;1172&#x2F;</a> hits the spot and is - what a coincidence - about emacs and workflows.

Assuming any particular commit in git represents the eventual state of a release seems foolhardy.

I someone is to fork Emacs its because of getting proper UI integration or multithreading.<p>This is just a neglectable, whimsical step. Sorry.<p>What Emacs needs is the nvim&#x2F;vim Schisma.