6 ms·

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'

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

NeutralForest 3y ago
I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".
bachmeier 3y ago
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 3y ago
  This is a pre-release commit not in any released version.
  - Beldin 3y ago
    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.
    - tptacek 3y ago
      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.
    - tsimionescu 3y ago
      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.
      - 3y ago
jeremyjh 3y ago
> 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.
- rightbyte 3y ago
  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 3y ago
    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.
jbluepolarbear 3y ago
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 3y ago
  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 3y ago
    The article says otherwise. It says that many concerns were disregarded during that time.
    - heyoni 3y ago
      Plenty of comments here saying that the change did more than make the feature opt in which is why it was rejected.
    - yaantc 3y ago
      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 3y ago
        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.
eduction 3y ago
>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 3y ago
  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 3y ago
    There is actually an easy answer. There is a bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394 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.
yaantc 3y ago
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
- disruptiveink 3y ago
  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.
Ferret7446 3y ago
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-revolution-and-the-vscode-gorilla/ 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.
kazinator 3y ago
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.
ChrisMarshallNY 3y ago
> 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.

NeutralForest 3y ago

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

bachmeier 3y ago

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 3y ago
This is a pre-release commit not in any released version.
- Beldin 3y ago
  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.
  - tptacek 3y ago
    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.
  - tsimionescu 3y ago
    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.
    - 3y ago

jeremyjh 3y ago

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

rightbyte 3y ago
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 3y ago
  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.

jbluepolarbear 3y ago

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 3y ago
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 3y ago
  The article says otherwise. It says that many concerns were disregarded during that time.
  - heyoni 3y ago
    Plenty of comments here saying that the change did more than make the feature opt in which is why it was rejected.
  - yaantc 3y ago
    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 3y ago
      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.

eduction 3y ago

>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 3y ago
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 3y ago
  There is actually an easy answer. There is a bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394 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.

yaantc 3y ago

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

disruptiveink 3y ago
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.

Ferret7446 3y ago

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-revolution-and-the-vscode-gorilla/ 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.

kazinator 3y ago

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.

ChrisMarshallNY 3y ago

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