Oh please. This is not someone's first step in an experimental new feature in its own branch.
This is a commit of a fully working non-trivial patch that alters long-standing UI to the master branch.
You're not supposed to merge in patches there on a whim.
It was not done on a whim. The author and the reviewers felt that the improvements outweighed the cost of the workflow change, which they explicitly discussed. That doesn't mean they got it right, but it's completely unfair to characterize it as "on a whim". Of course, you would not know this from the article - it's misrepresenting the discussion as it happened. In particular, while it correctly points out that a reviewer raised the issue and the patch author brushed it away somewhat, it fails to mention that the reviewer actually agreed with them afterwards.
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.
>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.
That is how all changes work, especially for an editor like Emacs where the internal APIs are public. As far as I understand, the accepted workflow for Emacs dev is:
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.
What I read (did not verify) was that two users discussed and decided on the feature. That's hardly a well deliberated change.
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.
Do you do a lot of emacs development? I certainly don't. I'm trying to piece together who here is talking about the norms of the Emacs development team and who's talking about their opinions of how software engineering should work everywhere.
