Maybe let'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' 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's still discussion if overwriting registers should prompt for confirmation (which it didn't use to do). Let'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...
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.
> 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)
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.
