Hacker News Reader

Comment by pilgrim0 | Hacker News Reader

I don’t fully understand the nature/impact of the change but this conflict seems so minor to me. Like, people on both sides display the same level of entitlement but for different reasons, and they all think they have their are “right”. Hum, no, for outsiders you all appear stubborn and lacking ability to compromise. “Oh my gosh, I’ll have to press 1 extra key now, this project is doomed!”, “no no no, this little change is the hallmark of security, it should be mandatory for every user”. Come on…

View on HN

I disagree. As a developer I think breaking literally decades old workflows for users without notice or any level of concern is a bad thing. For a program with users so reliant on muscle memory, I think the impact is far worse.

The friction seemed less about the change as such as in the unilateral delivery.

Even good change (whether or not this is) needs a gentle transition.

If I understood this correctly, the new behavior cannot be customized back to the old behavior. If that's true, then that's obviously very bad. Generally, as an Emacs user, I don't just want an opt-in or a gentle transition, I need to be able to customize everything to my needs.

This is Emacs, so one presumes that it's a SMOeL (Simple Matter Of eLisp) problem.

However, it seems tasteless to impose the burden.

> “Oh my gosh, I’ll have to press 1 extra key now ... "

is a genuine usability tragedy for folks who have 25+ years of muscle memory involved. There are no small number of emacs users, myself included, who fall into that category.

> "... this project is doomed!”

obviously it's not quite that bad, but any change to long-standing muscle memory is going to send countless users down a rabbit hole looking to undo that change.

That is a correct and fair assessment of the impact, assuming the change lands in a release as-is (which apparently it won't: https://lists.gnu.org/archive/html/emacs-devel/2023-12/msg00... )

Breaking backward compatibility should be reserved for extreme cases, and this doesn't sound like one. It's possible the way the author handled it was poor and caused part of the dispute, but I think the right thing would be to make such behavior opt-in or at least very easy to disable.

Inventing new things who cares, but for existing key sequences its a problem even if the new sequence would have been better. Imagine when some of these soft cars start adding power steering in an overnight update.

> Oh my gosh, I’ll have to press 1 extra key now

This key is in a context which is about as bad as Ctrl-C ("Do you really want to copy this text into clipboard? [Y/n]")

This is something that should just have been made as a new function not replacing an existing one. That way users have a choice between speed when they know what register to use and help when they don't.

Social problems caused by intense and antisocial personalities? In MY free software project?

It’s more common than you think.

not minor at all. you do something 100 times a day, adding multiple seconds to that time is not only wasting time, it is increasing the 'cognitive load' on the human brain.

this is why you find in a lot of Operations centers, people have a dozen different systems where time-wasting "improvements" like this have been made over 20+ years, so each little time-wasting "improvement" has added up over time so now it takes like 10 minutes to do something that should take 10 seconds. (in other words, "why does an Airline clerk have to spend 5 minutes typing in order to do something for my ticket/account", or "how did they mess up my request so badly", the answer is what im talking about)

what it all really boils down to is a fundamental lack of respect for other people. if you respected other people, you would not break their workflow like this and then dismiss their concerns as unimportant.

Would a guitarist be wrong to reject an instrument whose string had to be plucked twice before starting to vibrate?

Reply on news.ycombinator.com