It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any other key because "it makes things nicer" is clearly a bug.
I'm also not fond of Emacs's many subtle UX changes in the last couple of years. Enabling eldoc by default, changing "blink-matching-paren" default value... For each new Emacs release, I have to revisit my init.el and revert to the old behavior (thank you, elisp!), because suddenly things start to pop out or jump around. I get it; this is maybe to please the newer/younger crowd who are usually "in transit" - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with "a big bag of odor."
Thanks to elisp, you can bend Emacs any way you want, but don't change default behavior just because "it looks nice to me".
I actually think changing the default here may have been sensible. The problem is removing the old functionality entirely. This looks like a change to benefit new users (which is good) that had the hopefully unintended consequence of burning existing power users (which is very bad). The sensible compromise is to add a config flag that restores the old behavior while keeping the new default. From the outside, it's hard to see any reason other than pride for not doing that.
Pleasing the newer/younger crowd is important! The default experience of Emacs should make it possible for new users to get up to speed as quickly as possible. Else, Emacs will slowly fade to irrelevance until it is a museum piece. There are of course different views about how to approach this.
Of course, for any change there should be switches or other possibilities to restore the old user experience. Power users (especially of Emacs) can be expected to be able to maintain their init.el file. Even the case of Spacebar Heating[0] could be handled that way. The legacy of a genuine technical bug should not impact the rest of the community forever.
Some might point out that there are Emacs distributions out there that offer a modern experience. But these are hardly known to newcomers. Distribution shopping is a useless distraction before starting to use an editor which already has a higher-than-average learning curve.
> I get it; this is maybe to please the newer/younger crowd
This seems to miss the point of these changes. If you're only concerned with your own workflow then almost any changes that you didn't specifically request are annoying. However, if you're concerned with the continued development/relevance of the program then it becomes clear that change must occur. Taking into account both existing user's concerns and barriers to entry for new users.
Many of emacs defaults are pretty awful at introducing users to the "emacs" way of doing things while also failing at easing unfamiliar users in.
Where do users come from? People trying out the software and enjoying it. I'm quite glad that the emacs maintainers care about this, as I'm sure I've benefitted greatly from the contributions some of those people will have made.
Improving things that put new users off is often the same as improving things that annoy existing users. Keeping the spirit of the tool intact doesn't require doing everything the same way.
> If the last emacs user press C-x C-c for the last time in whatever years that is not a failure.
I disagree. It'd be just as much of a failure as emacs moving away from it's focus on extensibility/configurability. It's meant to be a useful tool, if no-one is interested in using it, then it has most likely failed at it's purpose.
On the current situation, after reading through the emacs-devel mailing list, it becomes clear that the author of this change - a long term user and contributor - was attempting to address an issue that had come up in his own workflow. He seemed interested in engaging with people who had concerns surrounding the change. The tone of the article is honestly embarrassing in comparison.
I agree. I’ve been using Emacs for approaching 20 years. In the past few years when I upgrade I’m noticing the same thing. Some font faces have the wrong colors, in one case an actual function was removed and Emacs wouldn’t start, some commands prompt slightly differently. I like to point at Emacs as being like Linux, that it’s a stable platform I can rely on, but do have to admit that more recently I don’t want to upgrade for fear of breakage.
Hell, I’m still on a version of magit from 2014 because they wouldn’t stop moving things around despite it being, in my opinion, done. In all other software in my life I have to put up with things constantly changing for silly reasons, Emacs is the one piece of software where I’m in control.
I fully empathize with the poster being infuriated with changing behavior. I might not agree with the way it’s being expressed. It’s sort of “et tu, Emacs?”
I'm also not fond of Emacs's many subtle UX changes in the last couple of years. Enabling eldoc by default, changing "blink-matching-paren" default value... For each new Emacs release, I have to revisit my init.el and revert to the old behavior (thank you, elisp!), because suddenly things start to pop out or jump around. I get it; this is maybe to please the newer/younger crowd who are usually "in transit" - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with "a big bag of odor."
Thanks to elisp, you can bend Emacs any way you want, but don't change default behavior just because "it looks nice to me".