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