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

151–160 of 250 posts

Re: Bad NEWS, Emacs

#151

Post by shadowgovt »

travisjungroth wrote: post #142
shadowgovt wrote: post #117

At the end of the day though, it's emacs. In lisp alone, you can get the old behavior back if you want it. I think usability decisions like this are one of the harder things to decide by committee in an open source project because they are, at the end of the day, questions of taste. And people can have conflicting and equally valid tastes. Here, a swap is being made between editing speed and accuracy, with the one pe…

This is equivocating. It’s not better for purely historical reasons, it’s just a bad trade of speed for accuracy. If you really want to be sure, is one return click enough? Maybe it should be two. Maybe a mouse click. You could throw in a five second cool down to be really sure. Obviously some of these ideas are worse than the status quo.

I don't dispute that two or more clicks or a mouse press would be a bad trade-off of speed for accuracy.

Why is one press of the enter key a bad trade-off of speed and accuracy besides "It's never been that way before?"

Re: Bad NEWS, Emacs

#152

Post by tsimionescu »

mynegation wrote: post #60

It’s been 20 years since I left Emacs, but I understand that this change is pretty disruptive. What I do not understand is why Emacs that prides itself in being the “kitchen sink” did not add an option to revert to the old behaviour.

They are adding it, most likely. The author of this article is just mad that they didn't accept their patch (which added a flag but also did away with all the other improvements).

Re: Bad NEWS, Emacs

#153

Post by yaantc »

jbluepolarbear wrote: post #143
tsimionescu wrote: post #138

Earlier quoted context omitted.

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.

The article says otherwise. It says that many concerns were disregarded during that time.

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

Re: Bad NEWS, Emacs

#154

Post by mahkoh »

rjzzleep wrote: post #81
lvncelot wrote: post #69

Earlier quoted context omitted.

This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?

Attracting new users for with the old behaviour is too complex maybe?

I believe Mozilla has been successful with a similar strategy.

Re: Bad NEWS, Emacs

#155

Post by rcthompson »

morelisp wrote: post #30
devnull3 wrote: post #11

I am a Vim guy. Can someone explain what exactly is broken?

They did the Emacs equivalent of adding a confirmation dialog to an action which some people do very frequently (like tens of times per minute). I think it also fundamentally breaks some rarer use cases I would have trouble explaining to non-Emacs users, but do seem somewhat valuable. It's not clear to me from the messages I read why this can't be worked around without a hard fork, although I do agree it's an obvious…

Looking at the commit diff, I don't see anything that necessitates a hard fork. The changes are all in elisp, not compiled C code. It looks like just evaluating the old version of register.el (perhaps with a few compatibility changes) in an Emacs session would revert everything to the old behavior.

Re: Bad NEWS, Emacs

#156

Post by [deleted] »

mixedmath wrote: post #33

I'll summarize my understanding. A commit that changes how copying (actually "registers", which is a bit more general than copying) works in emacs was recently accepted. Now emacs opens up a minibuffer that shows what is happening, requiring one to accept the change by hitting enter or equivalent. The OP thinks this is a terrible, breaking change as it changes default behavior (and possibly without the possibility of…

[deleted]

Re: Bad NEWS, Emacs

#157

Post by tsimionescu »

jbluepolarbear wrote: post #143
tsimionescu wrote: post #138

Earlier quoted context omitted.

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.

The article says otherwise. It says that many concerns were disregarded during that time.

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.

Re: Bad NEWS, Emacs

#158

Post by chongli »

yaantc wrote: post #131
chongli wrote: post #28

Earlier quoted context omitted.

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 "a…

Then there is bad faith, it's just bad faith on the part of the linked blogger.

Re: Bad NEWS, Emacs

#159

Post by rightbyte »

jeremyjh wrote: post #134
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.

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

Re: Bad NEWS, Emacs

#160

Post by tptacek »

Beldin wrote: post #149
rrix2 wrote: post #135

Earlier quoted context omitted.

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

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.

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.
Post reply on HN