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

161–170 of 250 posts

Re: Bad NEWS, Emacs

#161

Post by pmontra »

Exuma wrote: post #101
djha-skin wrote: post #32

Earlier quoted context omitted.

In Vim speak: Imagine you create a bunch of recorded keyboard macros that store stuff in different registers. Now this change comes and instead of typing `"ay` you have to press `"a y`. Indeed any time you store to a register (`"a`) you have to add an enter key. This breaks all of your keyboard macros and all of your muscle memory made over the past twenty years or more. This is why people are upset.

Ive used vim for 10+ years, and I have known about yanking to different registers, but usually I only use the main register 99.9999% of the time. can you explain your use cases for using multiple registers? I should start doing this perhaps, but I can't think of many times I want to copy more than one thing at once, maybe once a month? But I also could be not thinking of the right examples.

First thing I thought about: yank a line to a, yank another line to b; move somewhere into the file; paste from a, move two lines down, paste from b; repeat N times or create a macro for it. Basically it will be macro with two inputs, the contents of the a and b registers.

Re: Bad NEWS, Emacs

#162

Post by froh »

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…

thank you for this down to the facts summary.

Re: Bad NEWS, Emacs

#163

Post by tsimionescu »

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.

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 reviewer raised the issue and the patch author brushed it away somewhat, it fails to mention that the reviewer actually agreed with them afterwards.

I think that the core problem is the article author saw a change that broke their workflow and didn't investigate any further for why it was made. They simply assumed they knew better and got annoyed that others saw some value in the original change. The very way it is presented in the article - as a change to add a confirmation for register overwrites - is a misunderstanding. The actual purpose of the change was to make C-g, the Emacs "cancel" key, work with register commands. The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.

Re: Bad NEWS, Emacs

#164

Post by jmclnx »

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…

That is my understanding, and the change for v30 would very much annoy me also. I know nothing about lisp but I save items to registers all the time.

I hope if this change is not reverted I can find a macro snippet that would do that extract key for me. Already in Emacs to do simple things involves lots of keys. Some I have created macros to avoid the keys, but I am not expert enough to create one for this change.

Re: Bad NEWS, Emacs

#165

Post by ramses0 »

Exuma wrote: post #101
djha-skin wrote: post #32

Earlier quoted context omitted.

In Vim speak: Imagine you create a bunch of recorded keyboard macros that store stuff in different registers. Now this change comes and instead of typing `"ay` you have to press `"a y`. Indeed any time you store to a register (`"a`) you have to add an enter key. This breaks all of your keyboard macros and all of your muscle memory made over the past twenty years or more. This is why people are upset.

Ive used vim for 10+ years, and I have known about yanking to different registers, but usually I only use the main register 99.9999% of the time. can you explain your use cases for using multiple registers? I should start doing this perhaps, but I can't think of many times I want to copy more than one thing at once, maybe once a month? But I also could be not thinking of the right examples.

    "ayy - copy function signature

    "byy - copy return signature

    "ap "bp - paste either...

    :reg - show all registers

    "3p - paste 3rd "historical" register

    "_dd - delete into the /dev/null buffer (so you don't eat your `yy` register that you'd already yanked)
It's admittedly a bit of an advanced/esoteric feature, but being able to paste "this part" or "that part" being somewhat context dependent is useful.

Also useful in the context of macros... A, B, C being differing bits you might be "lifting", and then placing somewhere.

    i" / ia - recall (while in insert mode) the default, or the named register.
Imagine that your converting `function do_something() { ... }` to: `arr["do_something"] = function() { ... }`

You could delete the function name into "A", the function body into "B", then go back to your marked spot, and pull out the "A" into the hash key, and put "B" as the key value.

It's reeeally awkward and complicated until you use it and it becomes a natural part of your way of thinking. Then it becomes "simply" two extra characters to type when working with _any_ copy/paste task and then you have a super-power of 26 choices of holding things off to the side.

`$REG` is honestly one of the best "beginner" uses of registers. It lets you "inline type" what you've just lifted/cut. eg:

     vwy - yank visible word into default register
     V"ay - yank whole line into register "a"
     I"="+1 => `word = word + 1` (without having to exit insert mode!)
     "ap - paste the line from register "a"
...it's a small thing, but an important aspect of "vim as a live text-based programming language", having a few "hot" named variables / text strings, and being able to see them and manipulate them. It's literally just the double-quote key and ":reg" that gives you access to it.

Re: Bad NEWS, Emacs

#166

Post by accelbred »

This is a bad take by the author; users wanting stability should be on the release branch, or pin commits on master. It should be expected that the development branch is used to develop in-progress features. Sometimes these take a while to hammer out. If you follow master, you will have frequent breaking changes and should be comfortable reverting to a previous commit when theres something breaking your workflow. Better yet, stay on a release.

Re: Bad NEWS, Emacs

#167

Post by disruptiveink »

yaantc wrote: post #144
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…

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…

Eh. I don't think that argument holds water, unfortunately. Too often I've seen the "it's just a beta/unstable version, it's not finished, you can't raise issues like this!" attitude as an issue to shut down any form of discussion, or worse, to avoid having to think about the consequences of some action.

Of course, nearly 100% of the times the behaviour people were complaining about will be part of the stable release. There is no magical moment where things just magically get sorted pre-release unless people voice feedback, especially if it's intended behaviour, as it's very much the case here. So call me jaded, when someone says "it's just the main branch, don't complain!" I just hear "I will do whatever I want and when the new release rolls in everyone will just have to deal with it." Which is totally fair if that's how you want to run your project, just don't pretend otherwise.

An extra one, which isn't the case here but makes me roll my eyes every times it happens is the outrage of "how dare you raise an issue that was caused by a new pre-release iOS/MacOS version and very much seems to be an intended change in the OS behaviour, we don't support that!!", only for it to turn into the usual scramble "oh no, our software is broken on the new iPhones, who could have forseen this!!?" hours after the release version starts hitting the masses.

Re: Bad NEWS, Emacs

#168

Post by pdyc »

it indeed looks like a bad idea. New behavior should be optional, old behavior should be default so that it does not affects existing workflow of users. I am heavy emacs user but i use stable release, i hope this change does not makes into the stable release.

Re: Bad NEWS, Emacs

#169

Post by aeturnum »

eduction wrote: post #140
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 ori…

I think the thing being criticized is the tenor of the pushback. The suggestion that, because the blog author (Eshel Yaron)'s patch wasn't accepted and the change is still currently in, that the maintainers are "insistent not to budge" and that this "demonstrates clear disrespect for Emacs user preferences, and indeed their freedom."

The Yaron's attitude seems to suggest that there's an easy right answer here and that it's the thing he wants (and Emacs does now). A lot of his upset seems not to be about the idea of an option to support the new behavior (which he wrote a patch to support!), but about the attitude with which this was introduced. In return, he's coming at this issue with an attitude that seemed fit to match what he thinks the maintainers are bringing.

So that's why it's important to ask if this blog post has misunderstood the arc of changes to Emacs. If the pushback will probably result in the current default staying in the editor. Because assuming the old behavior is best, even though some maintainers like the new behavior, is just as high handed as forcing the new behavior.

Re: Bad NEWS, Emacs

#170

Post by Y_Y »

yaantc wrote: post #144
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…

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 me like you're comitting the same sin of misrepresenting your opponent to enhance your position.

Post reply on HN