Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bad NEWS, Emacs

eshelyaron.com

Post reply on HN
Print view View original

131–140 of 250 posts

Re: Bad NEWS, Emacs

#131

Post by yaantc »

chongli wrote: post #28
marcinzm wrote: post #9

Earlier quoted context omitted.

That's not the author's point. They did try to improve the behavior in a future commit and were shot down. Hard it seems. So were any requests from others to change this before release.

Not only that, but the author of the original offending change asked the author of this blog to write a patch to make the change optional within the UI and then rejected the patch that was written. That seems like bad faith to me.

Read the mailing list thread: the patch did much more than making the change optional, it did revert other related changes. That's why it was rejected. Other discussed changes were taken in, and it's not settled yet it seems: the discussion is on-going.

I find the reporting here very one sided and uselessly dramatic. I read the thread and don't see arrogance, just (sometimes strong) differences of opinion. Calling "arrogant" anyone who don't agree and fold to your view, and create drama and draw the crowd against one specific person (the initial change author, OK, but it was done with maintainers in the loop) where the crowd won't check the details is not OK in my book.

Re: Bad NEWS, Emacs

#132

Post by bachmeier »

tarsius wrote: post #110

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 hav…

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.

Re: Bad NEWS, Emacs

#133

Post by cratermoon »

mtraven wrote: post #111

Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.

You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.

Re: Bad NEWS, Emacs

#134

Post by jeremyjh »

tarsius wrote: post #110

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 hav…

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

Re: Bad NEWS, Emacs

#135

Post by rrix2 »

bachmeier wrote: post #132
tarsius wrote: post #110

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 hav…

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.

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

Re: Bad NEWS, Emacs

#136

Post by jbluepolarbear »

tarsius wrote: post #110

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 hav…

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.

Re: Bad NEWS, Emacs

#138

Post by tsimionescu »

jbluepolarbear wrote: post #136
tarsius wrote: post #110

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 hav…

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.

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.

Re: Bad NEWS, Emacs

#139

Post by Asooka »

deng wrote: post #100

Maybe let's keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs' features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There's still discussi…

No program feature should ever be designed to be "friendly to newbies".

Easy to use (in general) - yes; easy to learn - yes; hard to do accidentally - yes; low friction - yes; discoverable - yes. However, designing for the person who has never learned to use the feature inevitably leads to your program having a very low skill ceiling and being a disservice to power users.

Also, how do you know the new design is "friendly to newbies"? You're not a newbie and neither are any of the other Emacs developers. Without lots of user studies, you have no idea what is "friendly to newbies".

A more proper way to do this change would be to go "Hey, I've been running into an issue with using registers for a while and solved it for myself with this change. Let's add it as an option and vote on what the default should be." This is a much better approach, because

1. It is designed based on real user feedback. Even if it's just one user, people aren't unique, so there must be many like that person. "I like it this way" is a much stronger argument than "my imaginary newbie likes it this way".

2. It invites the rest of the community to decide on the default program behaviour. Software must serve its current users first and foremost. Thus, what the majority says should be the default is what the default should be.

This is where Volpiatto and Zaretskii went wrong. A change was made and pushed to solve an imaginary problem for imaginary users without involving the people actually affected. They broke their users' trust.

Re: Bad NEWS, Emacs

#140

Post by eduction »

tarsius wrote: post #110

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 hav…

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

Post reply on HN