[tsimionescu]

The review of the feature was happening in public on the mailing list. All those who contributed to that review had their concerns addressed, and the change was merged into the main branch (which is the development branch of Emacs). Only afterwards did others complain.

[jbluepolarbear]

The article says otherwise. It says that many concerns were disregarded during that time.

[yaantc]

The article is just his author view. Please read the emacs mailing list threads to get the full picture.

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

[kazinator]

Then there are people who don't follow master.

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.

[Kalq]

If you are this hypersensitive to change, it behooves you stay on a stable release and only upgrade after you've read the CHANGELOG and NEWS files.

[kazinator]

Someone hypersensitive to changes track changes as early as possible, and complain quickly and loudly.

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

[heyoni]

Plenty of comments here saying that the change did more than make the feature opt in which is why it was rejected.

[tsimionescu]

That's what the article says, but I checked the actual mailing lists. Any replies that asked for a change of this kind came in after the patch was finalized. Even this author's own complaints. And, the author in particular didn't understand, or seek to understand, why the patch was added in the first place. Instead, their proposed "fix" that they complain about in the article reverted all of the improvements the author and reviewers made. Upon being informed of this, they simply complained that those are useless changes:

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

[Y_Y]

Perhaps you could mention what these improvements are or give a link to the messages you're getting this information from?

[gray_-_wolf]

> into the main branch

into the master branch