To add, I have issues with the attitude shown by the blog author.

If you use the development branch, you can't raise hell when there's a breaking change: it's to be expected!

Then it's fine to disagree on some change and discuss this. I read the email thread, and I do not see "arrogance". Just strong disagreement. So yes, converging will take a bit of time... Calling publicly someone "arrogant" for not folding back to your view, and trying to raise the crowd (a good part of whom won't read the thread to make their own opinion) looks like bullying to me.

Saying that his patch to make the change optional has been disregarded, when it was rejected because it not only made the change optional (that would have been OK, and a patch for this asked for) but removed other changes is not honest.

Lastly, pointing out one person to blame when the whole discussion is done with the Emacs maintainers in the loop is also a no-go in my book.

As a close to 30 years Emacs user, thank you to all its contributors! (and to Thierry, as long time Helm user) May their skin by thick, it's unfortunately sometimes needed :-P

Of course, nearly 100% of the times the behaviour people were complaining about will be part of the stable release. There is no magical moment where things just magically get sorted pre-release unless people voice feedback, especially if it's intended behaviour, as it's very much the case here. So call me jaded, when someone says "it's just the main branch, don't complain!" I just hear "I will do whatever I want and when the new release rolls in everyone will just have to deal with it." Which is totally fair if that's how you want to run your project, just don't pretend otherwise.

An extra one, which isn't the case here but makes me roll my eyes every times it happens is the outrage of "how dare you raise an issue that was caused by a new pre-release iOS/MacOS version and very much seems to be an intended change in the OS behaviour, we don't support that!!", only for it to turn into the usual scramble "oh no, our software is broken on the new iPhones, who could have forseen this!!?" hours after the release version starts hitting the masses.

I agree with @tarsius on this: just give the discussion (and patches) some more time, and it's likely to end just OK from past experience.

Ultimately, the consequences of a patch, especially one that changes UX, can only really be evaluated after the community starts using it. People using the master branch of Emacs are basically those who wish to work as the QA engineers of Emacs. End-users use release branches or even pre-packaged releases from their distro.

So, the normal process for a UX change is to merge it to master in order to get comments on the impact. Based on comments, you can either revert, move behind a flag, etc.

Isn't this a bit of a loaded take too? I'm sure the author wouldn't agree that what they wanted was for Thierry to "fold back". I agree with your criticisms here in direction but not in magnitude, in fact it appears to me like you're comitting the same sin of misrepresenting your opponent to enhance your position.

If nobody raises hell on a development branch, the change will have a way of making it to the master branch.

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

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.

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

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

into the master branch

Even if the change could easily pass a technical review and get merged.

First you have to determine: do we need this for the product? If this change is made, does it break user workflows? What difficulties will users have if they pick up this change?

Then, people who agree to test out all changes to Emacs by using the head of master found, basically the QA department of Emacs, came back with feedback that they like some of the improvements, but that they don't like one particular aspect (the extra RET). Thierry started addressing them, and a setting to disable the feature was added - but the initial version missed the mark. The article author also was part of this process, and even proposed a patch, but their attitude made others ignore it after the initial review (their patch reverted all changes and only implemented a tiny subset of the original, behind the discussed flag).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394

Thierry opened this as a simple bug, but then implemented something with multiple enhancements rather than addressing the bug, while causing UX regressions.

It looks like only one developer was engaging the content, a Michael H., and he pointed out early, as far back as in October, both the problems that Eschel later latched onto.

Eschel came up with a patch that just addresses #66394 in a small way.

The reply to that was:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394#201

"But your patch only fixes this bug, reverting half a dozen features mine adds."

Using a bug ticket as a vector for introducing enhancements is a software engineering no-no.

They should merge the simplest patch that closes the bug without regressing anything or introducing extraneous enhancements. For those, a new enhancement ticket should be opened.

If Eschel's patch can close #66394, and not break anything, the consideration of that it doesn't implement another solution's enhancements is actually a plus.

There is possibly another bug ticket hiding in there based on the remark [y]ou reintroduced the old implementation which was not wrote correctly about handling various keys, particularly C-g. Existing behavior of not correctly handling various keys sounds like a problem different from the 66394 issue.

If the project doesn't want the simplest fix for an issue, but to address something architectural, like with a view for adding enhancements or whatever, that can be turned into another ticket where you articulate that. The original bug can then be marked pending or blocked by that with a note that we don't fix this until that one.

This reads as contradictory to me. On the one hand you’re saying that user response is a key input to making a final decision. Then you’re criticizing a negative user response as blowing things out of proportion. But if the users didn’t react, the original thing they are upset about probably would have happened, per your own description of the process.

I saw a very similar process unfold with clojure-mode, where rms floated the idea of rewriting it and taking control of the name from the original longtime author, a Clojure community member. The reason this didn’t happen is people got upset and posted to the list - but those very people who caused it not to happen were told they were blowing things out of proportion. So that doesn’t seem like a very meaningful criticism.

The Yaron's attitude seems to suggest that there's an easy right answer here and that it's the thing he wants (and Emacs does now). A lot of his upset seems not to be about the idea of an option to support the new behavior (which he wrote a patch to support!), but about the attitude with which this was introduced. In return, he's coming at this issue with an attitude that seemed fit to match what he thinks the maintainers are bringing.

So that's why it's important to ask if this blog post has misunderstood the arc of changes to Emacs. If the pushback will probably result in the current default staying in the editor. Because assuming the old behavior is best, even though some maintainers like the new behavior, is just as high handed as forcing the new behavior.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394

The bug's description is this:

"When using `copy-to-register`, it is hard to see which register is already taken in the preview buffer."

If Eshel Yaron's simpler patch is enough to close 66394, and doesn't break anything, that should be used.

Generally speaking.

If this has happened as described in the OP then I’m worried about the health of emacs. There was controversy before it was merged to master, and they merged it anyway. Breaking user workflows and not even making it optional, much less opt-in comes across as a callous disregard for user experience.

Especially in a project like Emacs, where every efficinado has their own really custom config.

I mean, reading the Emacs docs it is written in a way that make you feel like color display and a mouse is cutting edge hardware and optional.

It is a very conservative project ...

This is not to say that both the patch author and the reviewer didn't misjudge the importance of a workflow change. But no one was being hostile or dismissive - they discussed the issue, and concluded (probably wrongly) that the new behavior is overall better and wouldn't significantly impact anyone negatively.

Then, two days after it became available, other users started seeing it and raised bugs on the behavior, which the patch contributor started addressing. The author of this article was the first one to raise such an issue, and it wasn't initially clear how many others would agree with them. Still, the maintainers and the patch author agreed immediately that a flag to re-enable the old behavior would be a good thing, and asked if the article author would like to contribute it (the patch author wanted a break from this feature that they'd worked for weeks on). The article author came back with a patch that reverted all of the changes made by the original patch except for one. When told about this, they said that they only kept the changes that had any value, and that they'd require proof the other changes are also useful before going further - to which they didn't receive any more replies, for obvious attitude reasons.

It's not. The article is bad and wrong. It preemptively tries to dodge such accusations, but most of the hyperbole and "emotions" are just downright lies.

btw the person you responded to is the author of magit. I think his opinion should be weighted more heavily that the author of this article.

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.

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.

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.

Yes there was. Staying on version 29 of emacs. Or write everything that is needed in lisp to revert to old behavior.

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.

For me, emacs developers breaks things for users the least and highly value backwards compatibility.

If we aren't strongly considering reverting a breaking change immediately, that signals that the Emacs devs no longer value backward compatibility as highly, which means Emacs is abandoning many of its existing users.

https://www.murilopereira.com/the-values-of-emacs-the-neovim...

Core values matter. The Emacs maintainers did something that violated a core value, and the community is rightfully offended.

Also, same in every company I've ever worked in that had any kind of process.

I have been watching Emacs vs Vi wars for decades. People take this stuff seriously.

In my case, I tend to use GUI editors, whenever possible (or Nano/Pico, if absolutely forced to). I know, I know, I'm a wimp. Guilty as charged.