Users raising their concern started three days ago. That's not enough for this process to have concluded already.

Here's a recent message by Eli (and the message he is responding to).

    > I'm hoping the old behavior stays the default and the new behaviour
    > is what users can opt in with a variable.
    > 
    > If that is what normally happens for much less disruptive changes,
    > why isn'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.

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

Isn't this a bit of a loaded take too? I'm sure the author wouldn't agree that what they wanted was for Thierry to "fold back". I agree with your criticisms here in direction but not in magnitude, in fact it appears to me like you're comitting the same sin of misrepresenting your opponent to enhance your position.

If nobody raises hell on a development branch, the change will have a way of making it to the master branch.

Of course, nearly 100% of the times the behaviour people were complaining about will be part of the stable release. There is no magical moment where things just magically get sorted pre-release unless people voice feedback, especially if it's intended behaviour, as it's very much the case here. So call me jaded, when someone says "it's just the main branch, don't complain!" I just hear "I will do whatever I want and when the new release rolls in everyone will just have to deal with it." Which is totally fair if that's how you want to run your project, just don't pretend otherwise.

An extra one, which isn't the case here but makes me roll my eyes every times it happens is the outrage of "how dare you raise an issue that was caused by a new pre-release iOS/MacOS version and very much seems to be an intended change in the OS behaviour, we don't support that!!", only for it to turn into the usual scramble "oh no, our software is broken on the new iPhones, who could have forseen this!!?" hours after the release version starts hitting the masses.

I agree with @tarsius on this: just give the discussion (and patches) some more time, and it's likely to end just OK from past experience.

Ultimately, the consequences of a patch, especially one that changes UX, can only really be evaluated after the community starts using it. People using the master branch of Emacs are basically those who wish to work as the QA engineers of Emacs. End-users use release branches or even pre-packaged releases from their distro.

So, the normal process for a UX change is to merge it to master in order to get comments on the impact. Based on comments, you can either revert, move behind a flag, etc.

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.

The Yaron's attitude seems to suggest that there's an easy right answer here and that it's the thing he wants (and Emacs does now). A lot of his upset seems not to be about the idea of an option to support the new behavior (which he wrote a patch to support!), but about the attitude with which this was introduced. In return, he's coming at this issue with an attitude that seemed fit to match what he thinks the maintainers are bringing.

So that's why it's important to ask if this blog post has misunderstood the arc of changes to Emacs. If the pushback will probably result in the current default staying in the editor. Because assuming the old behavior is best, even though some maintainers like the new behavior, is just as high handed as forcing the new behavior.

GP is correct, and this is quite normal: some people using Emacs master will not follow all the mailing list discussions and commits. So they will notice a change only after it is merged. Nothing wrong with this, and nothing wrong with being unhappy about such a change. What's wrong in my book is the nature of the reaction show in this article (see my comment in reply to @tarsius).

Some people only pick up releases, including test releases.

Some people only work with final releases.

All those people could find something suddenly not working well.

Those who are not sensitive changes just use whatever Ubuntu (or whatever) provides and are unconcerned with the development.

> Indeed, I only reimplemented the parts I saw as clearly beneficial. Most importantly, my patch improves stuff without breaking other stuff.

> Perhaps you can explain your use case for the rest of the changes, and if there's a good and compatible way to add them I'll be happy to look into it at some point.

> > - No filtering. > > - No navigation. > > - No default registers. > > - No possibility to configure a new command added to register.

> If you could elaborate about these bullets, and explain their use, that'd be great.

I think it's quite obvious that engaging further with someone who came in with this attitude after a review was finalized (after ~5-10 rounds of feedback, I should point ou) and a patch applied did not seem worth it.

Even if the change could easily pass a technical review and get merged.

First you have to determine: do we need this for the product? If this change is made, does it break user workflows? What difficulties will users have if they pick up this change?

Then, people who agree to test out all changes to Emacs by using the head of master found, basically the QA department of Emacs, came back with feedback that they like some of the improvements, but that they don't like one particular aspect (the extra RET). Thierry started addressing them, and a setting to disable the feature was added - but the initial version missed the mark. The article author also was part of this process, and even proposed a patch, but their attitude made others ignore it after the initial review (their patch reverted all changes and only implemented a tiny subset of the original, behind the discussed flag).

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.

It's not. The article is bad and wrong. It preemptively tries to dodge such accusations, but most of the hyperbole and "emotions" are just downright lies.

btw the person you responded to is the author of magit. I think his opinion should be weighted more heavily that the author of this article.

Especially in a project like Emacs, where every efficinado has their own really custom config.

I mean, reading the Emacs docs it is written in a way that make you feel like color display and a mouse is cutting edge hardware and optional.

It is a very conservative project ...

This is not to say that both the patch author and the reviewer didn't misjudge the importance of a workflow change. But no one was being hostile or dismissive - they discussed the issue, and concluded (probably wrongly) that the new behavior is overall better and wouldn't significantly impact anyone negatively.

Then, two days after it became available, other users started seeing it and raised bugs on the behavior, which the patch contributor started addressing. The author of this article was the first one to raise such an issue, and it wasn't initially clear how many others would agree with them. Still, the maintainers and the patch author agreed immediately that a flag to re-enable the old behavior would be a good thing, and asked if the article author would like to contribute it (the patch author wanted a break from this feature that they'd worked for weeks on). The article author came back with a patch that reverted all of the changes made by the original patch except for one. When told about this, they said that they only kept the changes that had any value, and that they'd require proof the other changes are also useful before going further - to which they didn't receive any more replies, for obvious attitude reasons.

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.

I think that the core problem is the article author saw a change that broke their workflow and didn't investigate any further for why it was made. They simply assumed they knew better and got annoyed that others saw some value in the original change. The very way it is presented in the article - as a change to add a confirmation for register overwrites - is a misunderstanding. The actual purpose of the change was to make C-g, the Emacs "cancel" key, work with register commands. The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.

Regardless of the reasons for the change, a single author was permitted to commit a change that broke the workflows of potentially thousands of users. And there was no way users could work around it to maintain their previous workflows. That sounds arrogant and annoying.

1. Raise an issue through the mailing list.

2. Propose a patch on the mailing list

3. Maintainers send review comments about the patch.

4. The patch gets rejected or merged to master

5. The few people using head of master give feedback about the change

6. The change gets modified or reverted

7. A release branch is created from head of master

8. The bigger group of people who use un-released Emacs release branches start giving their feedback

9. More fixes are made on the release branch. Some features get reverted entirely.

10. A new Emacs release is decided and published

11. The larger emacs community starts using the brand new release and filing bugs and giving feedback

12. Release patches are sometimes issued, and other feedback is taken into consideration for the next release

13. After some minor releases, major Linux distributions start packaging the Emacs release to include in their official repos

14. Only now do the majority of Emacs users actually start using the new release, with all patches and feedback addressed.

In the case of this change, it has just made it at step 5 three days ago, and it is now in step 6. There is a LONG way to go before it makes it to any significant number of Emacs users. I actually doubt that there are thousands of users using head of master at all - out of which only a subset probably use registers in any way to begin with.

Personally, I've been using Emacs for 5+ years in my day to day job, and I am at a point where I build my own Emacs binaries. Even so, I'm only doing this from the latest release branch, and only close to a release, I don't have the energy to deal with the potentially broken head of a new release, even less so head of master.

I think for user facing features it makes more sense to provide new behaviors as opt-in, and go through a longer RFC period. Only if and when the new behavior is widely used and popular, then you flip the switch to default.

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.

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

A commit that changes how copying (actually "registers", 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 accept the change by hitting enter 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.

Let's state a vim analogy. If I want to copy the current line into my `d` register, I can type `"dyy`. This proposal would do something like, after typing `"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'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.

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.

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.

With paste you can see what got pasted, so you've got a chance to realize it is not what you wanted.

But how about for copy? If you meant to copy into register 'r' but missed by a key and typed 't' would it be noticeable right away?

I don't use Emacs so don't know how its undo works, but when I use named registers in Vim it is often to hold something that I'm not going to paste for quite a while. By the time I notice the error it would be annoying to undo all the way back to the mis-copy.

If copying into the wrong register was common enough to need to be addressed, my first thought would be something like adding a status message pups up for a short time near the cursor that says something like "Copied to 't'".

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.

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.

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.

I think that if the author of this rant did not come along and rant, there would be no "but is still being worked on" done. My reading is that the maintainer (Theirry) was happy with the extra RET.

NOW it is getting worked on because of the dogged and emotional criticism by the rant's author, prior to him writing his rant.

If he didn't make such an emotionally charged and disruptive arguments and patches, the rest of us poor Emacs users would have only found out about the broken workflow (extra RET) once the bug was fully baked in, requiring waiting for the next release in order to get a fix.

Then commands could just reference that list if needed.

You mean, "luckily for the entire fucking Emacs community, one of the small number of people who pick up unreleased master commits came along and happens to be a user of registers ..."

I'm not very familiar with Emacs, so possibly stupid questions incoming.

If you start to type C-x r SPC t to save to register t, does C-g work right after the C-X and the r?

If so is that because the C-x, r, and SPC are part of the command sequence whereas the t is just an argument used by the command, and the C-g handling is done in the command sequence processing?

Emacs is pretty famous for its flexibility in letting users bind and unbind key sequences to commands. Could people who like the old behavior fairly easily effectively restore it by unbinding the handler for C-x r SPC, and then bind handlers for C-x r SPC a, C-x r SPC b, C-X r SPC c, and so on for all registers they want to use, with each of those handlers just copying to the appropriate register?

That should let them use the same keystrokes they now use, and if my guess above about C-g handling is right also make C-g work to cancel after C-x r SPC.

But that probably just proves my novice status.

Currently, nothing. `y` isn't a defined motion.

?

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?

Even better: vim.highlight.on_yank

It seems like this option was mentioned before the original post was published, but perhaps the author didn't see this? I assume this would fix the issue, but I may be missing something.

--

EDIT: it looks like this will still require a RETURN keypress, based on the reply from ginko below.

https://yhetil.org/emacs/[email protected]/

Please also take note that this (completely reasonable email) is some of the so-called "bad behavior" and "arrogance" that the author of the article is purportedly describing.

The whole point of Emacs is that it is a radically customizable platform, and if you don'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.

Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.

Also, as soon as someone talks about "settings" there is usually a profound misunderstanding of how Emacs works at play.

Maybe just to persuade the mainline maintainers?

The only clue I see is in the polite objection the author quotes who writes "I agree it's safer..."

But I don't understand safer in what way or why 1 person gets to decide safer=better=forced.

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

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 `"ay`. 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.

    "ayy - copy function signature

    "byy - copy return signature

    "ap "bp - paste either...

    :reg - show all registers

    "3p - paste 3rd "historical" register

    "_dd - delete into the /dev/null buffer (so you don't eat your `yy` register that you'd already yanked)

Also useful in the context of macros... A, B, C being differing bits you might be "lifting", and then placing somewhere.

    i" / ia - recall (while in insert mode) the default, or the named register.

You could delete the function name into "A", the function body into "B", then go back to your marked spot, and pull out the "A" into the hash key, and put "B" as the key value.

It's reeeally awkward and complicated until you use it and it becomes a natural part of your way of thinking. Then it becomes "simply" two extra characters to type when working with _any_ copy/paste task and then you have a super-power of 26 choices of holding things off to the side.

`$REG` is honestly one of the best "beginner" uses of registers. It lets you "inline type" what you've just lifted/cut. eg:

     vwy - yank visible word into default register
     V"ay - yank whole line into register "a"
     I"="+1 => `word = word + 1` (without having to exit insert mode!)
     "ap - paste the line from register "a"

To really blow your mind:

    i%

    V:!ls

It's again, esoteric, but as you use it more, it becomes less esoteric and more just another part of your vim vocabulary (:help search-offset, fellow traveler).

Or when I select something and then paste and I actually wanted to keep my paste buffer and not replace it

This person seems to explain it well

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.

Additionally, some actions on top of the original behavior (that depended on Ctrl-C completing automatically, to keep with the analogy), now are just broken.

The downside is that you must push enter after you enter the register you want.

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)

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.”

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

https://news.ycombinator.com/reply?id=38592984&goto=item%3Fi...

and individuals involved have been receiving harassment:

https://www.reddit.com/r/emacs/comments/18f5oi9/comment/kcss...

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

”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. . .”

Anyway the author is peeved that they changed the default bindings such that there's a modal UI in the way of what used to be a fully-keyboard/home-row operation. It sounds like a reasonable complaint; I'd be annoyed too if they changed something that lived in my muscle memory like this kind of feature does.

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

From https://yhetil.org/emacs/[email protected]/

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.

Whether it's a good idea... well, I don't use registers but the whole thing seems like a bad idea to me. I don't think I know anyone who uses registers and would like the new behavior. (But I also understand the desire to modernize `register-read-with-preview` a bit. A better solution seems like it would be providing multiple implementations so users can do the register equivalent of `(fset #'yes-or-no-p #'y-or-n-p)` like every old Emacs user does today.)

In lisp alone, you can get the old behavior back if you want it.

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).

Me personally, I'm a committed emacs user and I don't have skin in this game. If I don't like the new UI, I'll just add the necessary code to swap it out for the old UI.

Why is one press of the enter key a bad trade-off of speed and accuracy besides "It's never been that way before?"

Imagine needing to hit return every time you ctrl-v. Really no point when ctrl-z is available.

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

I'm also not fond of Emacs's many subtle UX changes in the last couple of years. Enabling eldoc by default, changing "blink-matching-paren" 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/younger crowd who are usually "in transit" - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with "a big bag of odor."

Thanks to elisp, you can bend Emacs any way you want, but don't change default behavior just because "it looks nice to me".

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/

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.

If the last emacs user press C-x C-c for the last time in whatever years that is not a failure.

It's totally fine to disagree with people. Agreeing with people while doing the complete opposite, is quite unacceptable, in my opinion.

[1]: https://yhetil.org/emacs/[email protected]/

[2]: https://yhetil.org/emacs/[email protected]/

> 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.

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)

The maintainer already said: he thought it was a clear improvement, so it landed on master. Now that it has landed and people use it, people react to it, and it turns out the old behavior was well beloved and it's already decided it will stay through an option. Now further details are discussed. This has happened many times before. Just give it a bit of time, voice your opinion, and hopefully a consensus will be achieved (and if not, yes, the maintainer has the last word, that's how it supposed to be).

This is the master branch. It often takes months to flesh out these kind of things. You might say this should be done on a feature branch, but these get used much less and hence you'll get much less feedback.

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.

And now the drama is dialed to 11. I see no point in responding to such hyperbole.

I'd rather people who do regularly use the feature weigh in on how they feel about its new behavior.

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

I find the reporting here very one sided and uselessly dramatic. I read the thread and don't see arrogance, just (sometimes strong) differences of opinion. Calling "arrogant" anyone who don't agree and fold to your view, and create drama and draw the crowd against one specific person (the initial change author, OK, but it was done with maintainers in the loop) where the crowd won't check the details is not OK in my book.

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

You wouldn't even treat your dog like this.

No? It changes how an existing command behaves.

> 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.

It's not terrible, and the mnemonic is sound. If you don't like it, perfectly valid opinion, you're just not made for emacs' default behavior.

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.

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

Even good change (whether or not this is) needs a gentle transition.

However, it seems tasteless to impose the burden.

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 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]")

It’s more common than you think.

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.