Bad NEWS, Emacs

That’s a bad process. The review of the feature should start before it’s merged into main branch, not after. It totally reasonable for people to be upset with a breaking feature in main branch without discussing it with the community at large. Changes merged in like this are how long standing tool lose community support.

It would make a lot more sense to have a discussion before breaking long-used behavior. I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.

Thank you @tarsius! Couldn't have said it better.

To add, I have issues with the attitude shown by the blog author.

If you use the development branch, you can't raise hell when there's a breaking change: it's to be expected!

Then it's fine to disagree on some change and discuss this. I read the email thread, and I do not see "arrogance". Just strong disagreement. So yes, converging will take a bit of time... Calling publicly someone "arrogant" for not folding back to your view, and trying to raise the crowd (a good part of whom won't read the thread to make their own opinion) looks like bullying to me.

Saying that his patch to make the change optional has been disregarded, when it was rejected because it not only made the change optional (that would have been OK, and a patch for this asked for) but removed other changes is not honest.

Lastly, pointing out one person to blame when the whole discussion is done with the Emacs maintainers in the loop is also a no-go in my book.

As a close to 30 years Emacs user, thank you to all its contributors! (and to Thierry, as long time Helm user) May their skin by thick, it's unfortunately sometimes needed :-P

So I think this has been blown way out of proportion.

If this has happened as described in the OP then I’m worried about the health of emacs. There was controversy before it was merged to master, and they merged it anyway. Breaking user workflows and not even making it optional, much less opt-in comes across as a callous disregard for user experience.

Users raising their concern started three days ago. That's not enough for this process to have concluded already… So I think this has been blown way out of proportion.

This reads as contradictory to me. On the one hand you’re saying that user response is a key input to making a final decision. Then you’re criticizing a negative user response as blowing things out of proportion. But if the users didn’t react, the original thing they are upset about probably would have happened, per your own description of the process.

I saw a very similar process unfold with clojure-mode, where rms floated the idea of rewriting it and taking control of the name from the original longtime author, a Clojure community member. The reason this didn’t happen is people got upset and posted to the list - but those very people who caused it not to happen were told they were blowing things out of proportion. So that doesn’t seem like a very meaningful criticism.

In my organization (embedded development in VOIP area) we revert breaking changes immediately, as soon as the breakage is identified.

Also, same in every company I've ever worked in that had any kind of process.

I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".

I disagree. The Emacs community has, at least historically, strongly valued backward compatibility. Breaking existing users is just about the worst thing you could do in Emacs.

If we aren't strongly considering reverting a breaking change immediately, that signals that the Emacs devs no longer value backward compatibility as highly, which means Emacs is abandoning many of its existing users.

https://www.murilopereira.com/the-values-of-emacs-the-neovim...

Core values matter. The Emacs maintainers did something that violated a core value, and the community is rightfully offended.

> gee there sure are a lot of stubborn people on emacs-[%]

I have been watching Emacs vs Vi wars for decades. People take this stuff seriously.

In my case, I tend to use GUI editors, whenever possible (or Nano/Pico, if absolutely forced to). I know, I know, I'm a wimp. Guilty as charged.

I think this is a good summary of the article, but not a good summary of the problem if you look at the mailing list.

This whole thing seems to have started because Thierry found a few problems with the way registers work, and wanted to address them.

The most important flaw was that after you hit C-x r SPC (save-to-register), whatever key you hit next, you'd save the text into the register associated with that key. In particular, the universal Emacs cancel key, C-g, would not work here: instead, the text or position would be saved to a register called ^g. Similarly, if you accidentally hit "jump-to-register" or "insert-register", you couldn't cancel with C-g (or with any other key), you'd be forced to select a register and it's contents would be jumped to/ inserted (if any).

Secondly, registers can hold text, a position, or nothing. jump-to-register only works if a register holds a position, while insert-register expects a text. Emacs includes a preview of registers which are non-empty when invoking these commands, but it doesn't distinguish - it will show you a register that includes strings as an option for jump-to-register, even though it knows it won't work.

So, Thierry took the time to address all of these concerns, and to address other feedback about the code. The reviewers agreed that these are important changes even though they add some extra interaction, and that the breaking change (having to hit RET after selecting a normal registry, or having to use an extra key to save to a weird register like ^g) are worth the gains. After it was done, and compiled, it was added by the Emacs maintainers to the development branch.

The author of this article came along, asked for a switch to revert between the new and the old behavior, and was asked for a patch. They provided a patch that reverted all of the changes I mentioned before (so, no way to cancel the register commands, no way to get contextual help about which registers contain text VS position, nothing) and instead implemented an entirely different feature (confirmation on overwriting a non-empty register based on a flag). Thierry installed the author's new patch and gave this simple feedback, to which the author basically replied "you don't need all that".

Now, as more people started using the feature, the belief by Thierry and the original reviewers that the breaking change had minimal impact was proven wrong. Thierry started working on a new improvement to create a flag that keeps both all of his new work, but allows the previous workflow too (particularly, removing the extra RET, which was ultimately a side effect, not the main point). The patch missed the mark, but it is still being worked on.

Overall, it seems the process is working quite well, and it is only the author of this article that is trying to bully his way into the discussion and ignore the context, with a very anti-hacker attitude of "if it kinda works, we shouldn't change it in any way", which is very much against the spirit of Emacs.

As a perpetually novice vim user, I actually would have expected "dyy" to mean Delete the current line.

But that probably just proves my novice status.

Also, registers are a relatively advanced feature mostly used for rapid edits. Registers aren't aimed at first-time users using a mouse. They're aimed at high-speed typists doing complex things.

I used Emacs for decades, and never really got into registers. Personally, I tended to use kill&yank for copying, and to use either multiple cursors or one-off keyboard macros for complex edits. But Emacs has tons of optional, advanced editing features for people who want to rely on muscle memory.

Adding a confirmation keystroke here is a bit weird. It's a bit like taking an electric piano and adding a confirmation pedal to confirm unusual chords. It just adds one more step to a rapid, complex input operation.

But the other important thing to remember is that Emacs has excellent undo. You don't need to ask users, "Do you want to paste register 'd' containing '...'?", because you can just paste it, and let the user undo it if they chose the wrong register.

So making a breaking change here is odd, and offering no way to disable it would make a lot of users upset.

Emacs predates modern GUI conventions. It's never going to be as familiar to new users as vscodium. So I think there's a good argument for serving power users as well as possible. That isn't to say that Emacs should never tweak the default config or add user-friendly features like the menu bar or visible selections. But it does suggest leaving things like registers mostly alone.

I just learned a new feature of Vim. Thank you!

Fortunately I use evil mode so my workflow is unaffected, for now.

Implicitly the rest of the emacs dev community is at fault too.

?

I can’t tell what this comment is supposed to mean.

He disagrees; other people also felt similarly about it but, they were ignored.

They say, if you don’t like it, why don’t you contribute? …but he did and that wasn’t acceptable either, so he’s forked it.

Do you feel it’s out of order to walk your own path with free software if you disagree with the maintainers? Isn’t that the whole point of GNU?

A commit that changes how copying (...) works in emacs

To people who don't use Emacs, it should be made clear that standard copying (kill-ring-save, M-w by default) isn't affected, only more advanced saving to registers is. Registers aren't a superset of the clipboard (kill ring).

Edit: In addition, those in this thread claiming that the change won’t be configurable must have no idea of Emacs’ customizability, namely the “settings” are for convenience only, you can switch out all the code if you want to. This is in the elisp part of Emacs, even if it lands without change (doubt it, after reading the actual mailing list thread rather than this one-sided tantrum), someone will have a package within minutes changing the behavior. No, you don’t need a fork for that, the forking here is performative at best.

That is my understanding, and the change for v30 would very much annoy me also. I know nothing about lisp but I save items to registers all the time.

I hope if this change is not reverted I can find a macro snippet that would do that extract key for me. Already in Emacs to do simple things involves lots of keys. Some I have created macros to avoid the keys, but I am not expert enough to create one for this change.

yank from visual mode, which has a similar show-explicitly-what-is-being-copied behavior.

Even better: vim.highlight.on_yank

In Vim speak:

Imagine you create a bunch of recorded keyboard macros that store stuff in different registers. Now this change comes and instead of typing `"ay` you have to press `"a<Enter>y`. Indeed any time you store to a register (`"a`) you have to add an enter key. This breaks all of your keyboard macros and all of your muscle memory made over the past twenty years or more.

This is why people are upset.

It's explained in the article.

The Emacs development process

No, I'm not kidding

There is no focus, there's no objective, it seems the louder ideas win but there's no final idea of what Emacs should look like or what/how it should do or not

That's why such breaking changes get in without questioning (and even why they were using such functionality as registers in the first place)

They did the Emacs equivalent of adding a confirmation dialog to an action which some people do very frequently (like tens of times per minute). I think it also fundamentally breaks some rarer use cases I would have trouble explaining to non-Emacs users, but do seem somewhat valuable.

It's not clear to me from the messages I read why this can't be worked around without a hard fork, although I do agree it's an obvious bad decision to begin with, and obvious to me even as someone who barely uses this feature.

https://news.ycombinator.com/item?id=38591788

This person seems to explain it well

I disagree. As a developer I think breaking literally decades old workflows for users without notice or any level of concern is a bad thing. For a program with users so reliant on muscle memory, I think the impact is far worse.

“Oh my gosh, I’ll have to press 1 extra key now ... "

is a genuine usability tragedy for folks who have 25+ years of muscle memory involved. There are no small number of emacs users, myself included, who fall into that category.

"... this project is doomed!”

obviously it's not quite that bad, but any change to long-standing muscle memory is going to send countless users down a rabbit hole looking to undo that change.

This is something that should just have been made as a new function not replacing an existing one. That way users have a choice between speed when they know what register to use and help when they don't.

Oh my gosh, I’ll have to press 1 extra key now

This key is in a context which is about as bad as Ctrl-C ("Do you really want to copy this text into clipboard? [Y/n]")

Inventing new things who cares, but for existing key sequences its a problem even if the new sequence would have been better. Imagine when some of these soft cars start adding power steering in an overnight update.

Would a guitarist be wrong to reject an instrument whose string had to be plucked twice before starting to vibrate?

not minor at all. you do something 100 times a day, adding multiple seconds to that time is not only wasting time, it is increasing the 'cognitive load' on the human brain.

this is why you find in a lot of Operations centers, people have a dozen different systems where time-wasting "improvements" like this have been made over 20+ years, so each little time-wasting "improvement" has added up over time so now it takes like 10 minutes to do something that should take 10 seconds. (in other words, "why does an Airline clerk have to spend 5 minutes typing in order to do something for my ticket/account", or "how did they mess up my request so badly", the answer is what im talking about)

what it all really boils down to is a fundamental lack of respect for other people. if you respected other people, you would not break their workflow like this and then dismiss their concerns as unimportant.

Breaking backward compatibility should be reserved for extreme cases, and this doesn't sound like one. It's possible the way the author handled it was poor and caused part of the dispute, but I think the right thing would be to make such behavior opt-in or at least very easy to disable.

Social problems caused by intense and antisocial personalities? In MY free software project?

It’s more common than you think.

This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?

Yeah, sure. People tried for years to extract the reasoning behind Gnome 2 to Gnome 3 changes and still no one has any idea.

Almost as it's just and only petty power trips.

See: https://news.ycombinator.com/item?id=38592984

I imagine it's that reading user input through something other than the minibuffer is annoying, because if you have customized your input/editing keys, read-key generally won't reflect that.

While I understand your point, emacs is changing very specific behavior, that was intended, to do something new now. So I would say you're xkcd comment is slightly off.

If you use this stuff a lot, it is totally going to suck. Some thing has changed, that may or may not have a good technical reason, that means that after years of the program training you into behaving one way (and it's not like this is some crazy workflow you've invented yourself, right - this is literally you following the documented process) you're now being punished for it by having it not work.

You wouldn't even treat your dog like this.

I mean, we're talking about changing intended behavior here and not accepting any discussion regarding that. Just because you didn't use jump-to-register, doesn't mean no one does. Again, this is not people using unintended consequences of edge-case-behavior, this is people complaining (rightfully so) about regressions that stem from changing the intended UI.

I’m a VIM user, not an emacs user so I don’t have a dog in this fight, but if the equivalent change was made in VIM it would pretty much be unusable for me. My muscle memory related to this feature would be completely broken.

I can’t think of any such change in VIM being made without a setting to turn it off.

‘Default bindings’ sounds like it’s configurable to be different. Is it?

There are more than 62. One of the complaints is that the minibuffer breaks access to e.g. the C-a register. One person I know uses letters for positions and C-letter for text so while this may be a very edge case for some I imagine they will be very upset...

It’s basically global uac-mode for all buffers without the ability to turn it off. If it weren’t true it would be laughable.

I stopped using emacs a long while ago but I rely on x11 selection buffers (middle click paste) heavily so i can relate. I'd absolutly be miffed to find a confirmation model dialog shoved between each select and paste operation AND a lack of a setting to revert to the old behavior.

I say implement the old behavior as an option. It's literally a few extra lines of code.

Sounds like Eli is not married to this as the default behavior (I'm not a fan of it either).

From https://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/

Eli says:

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.

This is equivocating. It’s not better for purely historical reasons, it’s just a bad trade of speed for accuracy. If you really want to be sure, is one return click enough? Maybe it should be two. Maybe a mouse click. You could throw in a five second cool down to be really sure. Obviously some of these ideas are worse than the status quo.

Once a new version of my favorite file manager came out with remapped key bindings. I can't even remember the name of it now. But my own anger was memorable as totally out of proportion even when I was feeling it. My investment in muscle memory had been trashed! I thought several evil thoughts before calming down. So while it sounds trivial I can understand why the reaction to the crime of Betrayal of Muscle Memory has escalated to "fork you".

At a minimum switching anything that breaks muscle memory should be a toggle that defaults to "keep my config how it used to be"

More generally, any frequently used software should be made “muscle-memorizable”, and then should not break it in later versions without good reasons. Muscle memory has the benefit of enabling “blind” and semi-asynchronous operation of the software, without constant visual confirmation for each micro-interaction. There’s unfortunately a trend in desktop software to make operation by keyboard ever more cumbersome or outright impossible.

Not just emacs. I don’t care about emacs at all. What makes this story important is pointing out the arrogance of devs that love to “improve” things without any regard for people’s settled expectations. That applies as much to google maps or iOS as it does to emacs.

I get it; this is maybe to please the newer/younger crowd

This seems to miss the point of these changes. If you're only concerned with your own workflow then almost any changes that you didn't specifically request are annoying. However, if you're concerned with the continued development/relevance of the program then it becomes clear that change must occur. Taking into account both existing user's concerns and barriers to entry for new users.

Many of emacs defaults are pretty awful at introducing users to the "emacs" way of doing things while also failing at easing unfamiliar users in.

Pleasing the newer/younger crowd is important! The default experience of Emacs should make it possible for new users to get up to speed as quickly as possible. Else, Emacs will slowly fade to irrelevance until it is a museum piece. There are of course different views about how to approach this.

Of course, for any change there should be switches or other possibilities to restore the old user experience. Power users (especially of Emacs) can be expected to be able to maintain their init.el file. Even the case of Spacebar Heating[0] could be handled that way. The legacy of a genuine technical bug should not impact the rest of the community forever.

Some might point out that there are Emacs distributions out there that offer a modern experience. But these are hardly known to newcomers. Distribution shopping is a useless distraction before starting to use an editor which already has a higher-than-average learning curve.

[0]: https://xkcd.com/1172/

I actually think changing the default here may have been sensible. The problem is removing the old functionality entirely. This looks like a change to benefit new users (which is good) that had the hopefully unintended consequence of burning existing power users (which is very bad). The sensible compromise is to add a config flag that restores the old behavior while keeping the new default. From the outside, it's hard to see any reason other than pride for not doing that.

fail to see why one would need to write a long blog post and maintain a fork because of something like this...

Probably because, and it certainly appears the case, that the process is being ruled by fiat not by good technical/policy decisions (and the approach of broadcast is intended to replace the fiat by overwhelming numbers)

No program feature should ever be designed to be "friendly to newbies".

Easy to use (in general) - yes; easy to learn - yes; hard to do accidentally - yes; low friction - yes; discoverable - yes. However, designing for the person who has never learned to use the feature inevitably leads to your program having a very low skill ceiling and being a disservice to power users.

Also, how do you know the new design is "friendly to newbies"? You're not a newbie and neither are any of the other Emacs developers. Without lots of user studies, you have no idea what is "friendly to newbies".

A more proper way to do this change would be to go "Hey, I've been running into an issue with using registers for a while and solved it for myself with this change. Let's add it as an option and vote on what the default should be." This is a much better approach, because

1. It is designed based on real user feedback. Even if it's just one user, people aren't unique, so there must be many like that person. "I like it this way" is a much stronger argument than "my imaginary newbie likes it this way".

2. It invites the rest of the community to decide on the default program behaviour. Software must serve its current users first and foremost. Thus, what the majority says should be the default is what the default should be.

This is where Volpiatto and Zaretskii went wrong. A change was made and pushed to solve an imaginary problem for imaginary users without involving the people actually affected. They broke their users' trust.

Context: I'm an Emacs user for 20 years...

There was a change committed which made using registers more friendly to use for newbies.

...and didn't realize this feature existed.

Maybe let's keep the drama down a bit?

Agreed, this is non-news.

Sure, in the sense that they can differ and co-exist? Of course it's much better in OSS when differences can be resolved so that more people may work together on fewer forks, so discussion should come before forks most of the time. The author seems to be doing exactly the right thing - tried to contribute to the shared work, voice their concerns and thought process, and ultimately fork in protest.

Yup. Great isn't it when the system works as intended.

Just because a system works doesn’t mean all outcomes out of the system when it’s working are equally good.

Even the best working system will still require people to make good decisions to have the best outcomes.

Absolutely not! Free Software working as intended. Are you trying to trigger RMS by calling Emacs "Open Source"?

There was Xemacs back in the day… and I guess it is still around.

What Emacs needs is the nvim/vim Schisma.

It's already had like six, over the decades.

There are enough unsuccessful forks of GNU Emacs. None of them get enough attention and support for whatever reason, but I guess mainly because there have no real reason to exist. Emacs devs are working diligently and improving it regularly, and there is no good and simple solution for the problems it has.

There won't be any nvim/vim-like Schisma happen, unless some super-dev appears who can outsmart the whole community and it's devs. Maybe, in a decade when AI become good enough and someone feeds Emacs to electron or something like that.

The impact of these forks is that the community around the main project is slowly eroded. But it doesn't really matter whether the fork brings the main project to the negotiation table. The author of TA is able and is committed to carry and maintain that patch in his local repository until the end of time. What is missing to complete such a fork is publishing that local repository.

From the blog post, I couldn't really tell what the author's long term intentions were for his fork.

Maybe just to persuade the mainline maintainers?

That's not the author's point. They did try to improve the behavior in a future commit and were shot down. Hard it seems. So were any requests from others to change this before release.

Seems like that still needs an extra RET to confirm register overwrites:

https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/

From that thread it does appear that register-use-previews seems to be the toggle for this behavior (although it mentions a bug where even if it’s set to never a certain workflow is prompting a confirmation). That would resolve any concerns I’d imagine if it’s truly an option?

It'll take me a day or two to get used to it and then it'll be fine for me. But I only really use registers to quickly jump around in buffers. If no configuration for switching to the old behaviour makes it in before Emacs 30 is released I'd be surprised if it were to take more than a week before someone makes a package that adds the old behaviour back in.

As a long-time emacs user who's never used registers I still think this is very poor form from the maintainers.

Emacs should be about customization and changing such a basic feature without a way to return to the original behavior is pretty bad.

For an established tool like Emacs, it must be hard to decide when it's okay to break the interface. Especially for a text editor, where longtime users' flow benefits from muscle memory.

You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.

People who don’t know what registers are aren’t affected by the change, so it’s not clear why they should be weighing in.

And criticizing a person’s decisions doesn’t amount to “demonizing”.

The actual reasonable approach would be to implement it as a strictly opt-in feature for the next release and then when many people have tested it, gather some some usage data and then decide on whether to make it the new default behavior or not.

Just breaking established user behavior and muscle memory just because you think something might be better without having gathered any actual evidence is insane.

I like how RMS pops up and complains about a Github link requiring non-free software and then returns to what ever he was doing.

They are adding it, most likely. The author of this article is just mad that they didn't accept their patch (which added a flag but also did away with all the other improvements).