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

181–190 of 250 posts

Re: Bad NEWS, Emacs

#181

Post by Y_Y »

tsimionescu wrote: post #147
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…

I think this is a good summary of the article, but not a good summary of the problem if you look at the mailing list. This whole thing seems to have started because Thierry found a few problems with the way registers work, and wanted to address them. The most important flaw was that after you hit C-x r SPC (save-to-register), whatever key you hit next, you'd save the text into the register associated with that key. I…

Makes me wonder why they didn't decree, "no using a register called ^g, that's a special character" and add a check when specifying a register. I bet it would break fewer workflows.

Re: Bad NEWS, Emacs

#182

Post by yaantc »

Y_Y wrote: post #170
yaantc wrote: post #144

Earlier quoted context omitted.

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…

> 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. Isn't this a bit of a loaded take too? I'm sure the author wouldn't agree that what they wanted was for Thierry to "fold back". I agree with your criticisms here in direction but not in magnitude, in fact it appears to m…

That could be, the author may not have expected nor intended the exposition of an HN post. If so, my apologies. I still find the article unfair and biased in its presentation, compared to the email list discussion. It's unfortunate, because if one look the comments here it's clear many take the article at face value and haven't read the list thread.

Re: Bad NEWS, Emacs

#183

Post by timmytokyo »

tsimionescu wrote: post #163
Beldin wrote: post #149

Earlier quoted context omitted.

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.

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

>The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.

Regardless of the reasons for the change, a single author was permitted to commit a change that broke the workflows of potentially thousands of users. And there was no way users could work around it to maintain their previous workflows. That sounds arrogant and annoying.

Re: Bad NEWS, Emacs

#184

Post by duskwuff »

Schiphol wrote: post #86
CoastalCoder wrote: post #65

Earlier quoted context omitted.

Ah, thanks. You're right, my brain parsed the gp's comment as simply "dyy".

Just for completion, `dd` deletes the current line in vim. I'm not sure what `dyy` should do, if anything.

> I'm not sure what `dyy` should do, if anything.

Currently, nothing. `y` isn't a defined motion.

Re: Bad NEWS, Emacs

#185

Post by medstrom »

ekidd wrote: post #104
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…

Also, registers are a relatively advanced feature mostly used for rapid edits. Registers aren't aimed at first-time users using a mouse. They're aimed at high-speed typists doing complex things. I used Emacs for decades, and never really got into registers. Personally, I tended to use kill&yank for copying, and to use either multiple cursors or one-off keyboard macros for complex edits. But Emacs has tons of optional…

Great points! If you don't participate in emacs development, maybe it's time to consider it.

Re: Bad NEWS, Emacs

#186

Post by medstrom »

Y_Y wrote: post #181
tsimionescu wrote: post #147

Earlier quoted context omitted.

I think this is a good summary of the article, but not a good summary of the problem if you look at the mailing list. This whole thing seems to have started because Thierry found a few problems with the way registers work, and wanted to address them. The most important flaw was that after you hit C-x r SPC (save-to-register), whatever key you hit next, you'd save the text into the register associated with that key. I…

Makes me wonder why they didn't decree, "no using a register called ^g, that's a special character" and add a check when specifying a register. I bet it would break fewer workflows.

Well, exceptions for C-g shouldn't have to be hardcoded everywhere, because that makes it harder to move the C-g behavior to some other key. If going this route, I'd first implement a list of "keys with C-g-like behavior" that can be given more members than just C-g, via a startup flag or some such.

Then commands could just reference that list if needed.

Re: Bad NEWS, Emacs

#187

Post by gray_-_wolf »

tsimionescu wrote: post #138
jbluepolarbear wrote: post #136

Earlier quoted context omitted.

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.

> into the main branch

into the master branch

Re: Bad NEWS, Emacs

#188

Post by nanny »

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.

>If this has happened as described in the OP

It's not. The article is bad and wrong. It preemptively tries to dodge such accusations, but most of the hyperbole and "emotions" are just downright lies.

btw the person you responded to is the author of magit. I think his opinion should be weighted more heavily that the author of this article.

Re: Bad NEWS, Emacs

#189

Post by medstrom »

PaulHoule wrote: post #15
jhoechtl wrote: post #10

I someone is to fork Emacs its because of getting proper UI integration or multithreading. This is just a neglectable, whimsical step. Sorry. What Emacs needs is the nvim/vim Schisma.

There was Xemacs back in the day… and I guess it is still around.

It's still around in the same sense that twm is still around.

Re: Bad NEWS, Emacs

#190

Post by nanny »

GavinAnderegg wrote: post #105
ginko wrote: post #99

Earlier quoted context omitted.

Seems like that still needs an extra RET to confirm register overwrites: https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/

Aha! Ok, that makes sense. I had figured the original poster would have seen this fly by, so I was confused as to why it was still an issue. Thanks!

Thierry also already offered to add another option to fully revert to the old behavior: https://yhetil.org/emacs/874jgq0zdh.fsf@posteo.net/

Please also take note that this (completely reasonable email) is some of the so-called "bad behavior" and "arrogance" that the author of the article is purportedly describing.

Post reply on HN