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

101–110 of 250 posts

Re: Bad NEWS, Emacs

#101

Post by Exuma »

djha-skin wrote: post #32
devnull3 wrote: post #11

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

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.

Re: Bad NEWS, Emacs

#102

Post by layer8 »

BaculumMeumEst wrote: post #95

I think a more effective approach to getting this reverted would be to actually describe the problem for people who don’t know what registers are, and to include the reasoning for the change, so that people can actually weigh the pros and cons and form an opinion. I also think you can leave out the names of individuals, you can discuss the idea on its merits without their identities being involved. All it accomplishe…

People who don’t know what registers are aren’t affected by the change, so it’s not clear why they should be weighing in.

And criticizing a person’s decisions doesn’t amount to “demonizing”.

Re: Bad NEWS, Emacs

#103

Post by addicted »

GavinAnderegg wrote: post #88

Reviewing the mailing list threads on this, it looks like there will be an option to revert this behaviour: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t It seems like this option was mentioned before the original post was published, but perhaps the author didn't see this? I assume this would fix the issue, but I may be missing something. -- EDIT: it looks like this will still require a RETURN keypress, based…

From that thread it does appear that register-use-previews seems to be the toggle for this behavior (although it mentions a bug where even if it’s set to never a certain workflow is prompting a confirmation). That would resolve any concerns I’d imagine if it’s truly an option?

Re: Bad NEWS, Emacs

#104

Post by ekidd »

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, advanced editing features for people who want to rely on muscle memory.

Adding a confirmation keystroke here is a bit weird. It's a bit like taking an electric piano and adding a confirmation pedal to confirm unusual chords. It just adds one more step to a rapid, complex input operation.

But the other important thing to remember is that Emacs has excellent undo. You don't need to ask users, "Do you want to paste register 'd' containing '...'?", because you can just paste it, and let the user undo it if they chose the wrong register.

So making a breaking change here is odd, and offering no way to disable it would make a lot of users upset.

Emacs predates modern GUI conventions. It's never going to be as familiar to new users as vscodium. So I think there's a good argument for serving power users as well as possible. That isn't to say that Emacs should never tweak the default config or add user-friendly features like the menu bar or visible selections. But it does suggest leaving things like registers mostly alone.

Re: Bad NEWS, Emacs

#105

Post by GavinAnderegg »

ginko wrote: post #99
GavinAnderegg wrote: post #88

Reviewing the mailing list threads on this, it looks like there will be an option to revert this behaviour: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t It seems like this option was mentioned before the original post was published, but perhaps the author didn't see this? I assume this would fix the issue, but I may be missing something. -- EDIT: it looks like this will still require a RETURN keypress, based…

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!

Re: Bad NEWS, Emacs

#106

Post by samus »

TheRoque wrote: post #87

[flagged]

Because of this change, the author of TA will likely have to perform 6000 keystrokes more per day since he is a poweruser of that feature. And this is just one user. Seems entirely justified.

Re: Bad NEWS, Emacs

#108

Post by [deleted] »

CoastalCoder wrote: post #68
wavemode wrote: post #64

This thread is mostly "I don't use this feature of Emacs (or Emacs at all) therefore this isn't a real problem, so stop complaining." Poor to see. I'd rather people who do regularly use the feature weigh in on how they feel about its new behavior.

For an established tool like Emacs, it must be hard to decide when it's okay to break the interface. Especially for a text editor, where longtime users' flow benefits from muscle memory.

[deleted]

Re: Bad NEWS, Emacs

#109

Post by davidkunz »

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…

> yank from visual mode, which has a similar show-explicitly-what-is-being-copied behavior.

Even better: vim.highlight.on_yank

Re: Bad NEWS, Emacs

#110

Post by tarsius »

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 have concluded already.

Here's a recent message by Eli (and the message he is responding to).

    > I'm hoping the old behavior stays the default and the new behaviour
    > is what users can opt in with a variable.
    > 
    > If that is what normally happens for much less disruptive changes,
    > why isn't it happening for this deep impacting one?
    
    Because the original discussion of these changes, between two people
    who were interested and involved, indicated that the new behavior
    makes much more sense than the old one.  Now, that others chimed in
    with the opposite views, we are still discussing what should be the
    behavior, and once that is concluded, we can talk about the defaults.
So I think this has been blown way out of proportion. IMO there are some serious issues in how Emacs is developed. I don't have a solution but I think that us users/package-maintainers thinking to ourselves "gee there sure are a lot of stubborn people on emacs-devel, what's wrong with them?" and then the second a change is made that we strongly disagree with, we start behaving like the world is ending, that might be a problem. This is how maintainers get defensive (you might have noticed that in the projects that you maintain).
Post reply on HN