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.

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

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.

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.

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.

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.

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.

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

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.

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

Referring of course to https://lkml.org/lkml/2012/12/23/75

Arguing that because something has been committed to the development branch it can't be reverted, is a terrible policy.

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.

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.

But that probably just proves my novice status.

?

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

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

This person seems to explain it well

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)

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.