[tarsius]

When a breaking change is made on Emacs' development branch, whether intentionally or not, and some users voice concerns about that change, then the change isn't reverted the minute those concerns are raised. The pros and cons are discussed, different solutions are implemented and improved, and finally a compromise is found.

Users raising their concern started three days ago. That's not enough for this process to have concluded already.

Here's a recent message by Eli (and the message he is responding to).

    > I'm hoping the old behavior stays the default and the new behaviour
    > is what users can opt in with a variable.
    > 
    > If that is what normally happens for much less disruptive changes,
    > why isn't it happening for this deep impacting one?
    
    Because the original discussion of these changes, between two people
    who were interested and involved, indicated that the new behavior
    makes much more sense than the old one.  Now, that others chimed in
    with the opposite views, we are still discussing what should be the
    behavior, and once that is concluded, we can talk about the defaults.

So I think this has been blown way out of proportion. IMO there are some serious issues in how Emacs is developed. I don't have a solution but I think that us users/package-maintainers thinking to ourselves "gee there sure are a lot of stubborn people on emacs-devel, what's wrong with them?" and then the second a change is made that we strongly disagree with, we start behaving like the world is ending, that might be a problem. This is how maintainers get defensive (you might have noticed that in the projects that you maintain).

[yaantc]

Thank you @tarsius! Couldn't have said it better.

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

[Y_Y]

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

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.

[yaantc]

That could be, the author may not have expected nor intended the exposition of an HN post. If so, my apologies. I still find the article unfair and biased in its presentation, compared to the email list discussion. It's unfortunate, because if one look the comments here it's clear many take the article at face value and haven't read the list thread.

[kazinator]

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

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

[disruptiveink]

Eh. I don't think that argument holds water, unfortunately. Too often I've seen the "it's just a beta/unstable version, it's not finished, you can't raise issues like this!" attitude as an issue to shut down any form of discussion, or worse, to avoid having to think about the consequences of some action.

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.

[yaantc]

There's a misunderstanding here: I'm not saying "don't complain". Complaining in itself is fine, and others are complaining on this topic in a way that looks OK to me (and will probably be more efficient too). It's the nature of this specific article complaint that I have a problem with.

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.

[achikin]

I wonder why wasn’t this patch given time before merging it? Isn’t that the whole purpose of patches and merge process?

[uranusjr]

Because merging into main better exposes the proposal to a more diverse crowd and attracts needed feedback. Especially when you’re managing multiple proposed features, it’s not viable for a mass of users to check out and test those from their individual branches. Without merging fast, you can only gather opinions from people actively reviewing patches, which are a far more minority group and likely to be biased.

[tsimionescu]

What kind of time? It spent around two months between the first proposal and being merged. Do you think that people would have trawled through the mailing lists and found this and given their reviews if only it had been given 1 more week?

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.

[eduction]

>Users raising their concern started three days ago. That's not enough for this process to have concluded already… So I think this has been blown way out of proportion.

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.

[aeturnum]

I think the thing being criticized is the tenor of the pushback. The suggestion that, because the blog author (Eshel Yaron)'s patch wasn't accepted and the change is still currently in, that the maintainers are "insistent not to budge" and that this "demonstrates clear disrespect for Emacs user preferences, and indeed their freedom."

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.

[kazinator]

There is actually an easy answer. There is a bug:

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.

[achikin]

Here is the recap of someone is interested https://metaredux.com/posts/2023/09/09/clojure-support-in-em...

[jbluepolarbear]

That’s a bad process. The review of the feature should start before it’s merged into main branch, not after. It totally reasonable for people to be upset with a breaking feature in main branch without discussing it with the community at large. Changes merged in like this are how long standing tool lose community support.

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

[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

[kazinator]

On the job, I wouldn't go implementing whatever pops into my head without input from my manager and product management.

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?

[tsimionescu]

Emacs is a community-driven project. And the author of this patch identified several issues with the feature, created a fix, proposed it for review, debated the impact with other devs on the mailing list for weeks, addressed all concerns raised, and then finally other more senior devs merged the change to master, where all new unstable changes go.

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

[kazinator]

I've now read (or at least skimmed) this in it entirety:

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.

[gpderetta]

Does Emacs even do enhancement tickets? It is a community driven project where people implement what they want to scratch an itch and get merged as long as they convince enough people; it is not a PM driven one with roadmaps, sprints and narrowly defined features.

[Ferret7446]

I disagree. The Emacs community has, at least historically, strongly valued backward compatibility. Breaking existing users is just about the worst thing you could do in Emacs.

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.

[jeremyjh]

> So I think this has been blown way out of proportion.

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.

[nanny]

>If this has happened as described in the OP

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.

[rightbyte]

Ye once the devs go user hostile it is all down hill from there.

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

[tsimionescu]

But that is not what happened. The author of this article is misrepresenting the attitude of everyone involved. There was a single reviewer who noticed the patch and started engaging with it, Michael, and while he originally raised the concern quoted in the article, he discussed with the patch author and they finally got to a common ground, he suggested several other improvements that the patch author worked on, and finally he is the one who approved the patch to move further - in a process that took almost two months.

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.

[NeutralForest]

I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".

[kazinator]

In my organization (embedded development in VOIP area) we revert breaking changes immediately, as soon as the breakage is identified.

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

[bachmeier]

It would make a lot more sense to have a discussion before breaking long-used behavior. I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.

[rrix2]

This is a pre-release commit not in any released version.

[Beldin]

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.

[tsimionescu]

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.

[timmytokyo]

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

[tsimionescu]

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.

[prmoustache]

> And there was no way users could work around it to maintain their previous workflows.

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

[smaudet]

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.

[_a_a_a_]

Can you link to what you read please

[tptacek]

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.

[ParetoOptimal]

> I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.

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

[ChrisMarshallNY]

> gee there sure are a lot of stubborn people on emacs-[%]

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.