Live data from Hacker News

Bad NEWS, Emacs

eshelyaron.com

91–100 of 250 posts

Re: Bad NEWS, Emacs

#91
post #70

It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any oth…

[deleted]

Re: Bad NEWS, Emacs

#92
post #70

It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any oth…

I actually think changing the default here may have been sensible. The problem is removing the old functionality entirely. This looks like a change to benefit new users (which is good) that had the hopefully unintended consequence of burning existing power users (which is very bad). The sensible compromise is to add a config flag that restores the old behavior while keeping the new default. From the outside, it's hard to see any reason other than pride for not doing that.

Re: Bad NEWS, Emacs

#93

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…

> A commit that changes how copying (...) works in emacs

To people who don't use Emacs, it should be made clear that standard copying (kill-ring-save, M-w by default) isn't affected, only more advanced saving to registers is. Registers aren't a superset of the clipboard (kill ring).

Edit: In addition, those in this thread claiming that the change won’t be configurable must have no idea of Emacs’ customizability, namely the “settings” are for convenience only, you can switch out all the code if you want to. This is in the elisp part of Emacs, even if it lands without change (doubt it, after reading the actual mailing list thread rather than this one-sided tantrum), someone will have a package within minutes changing the behavior. No, you don’t need a fork for that, the forking here is performative at best.

Re: Bad NEWS, Emacs

#94

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.

Maybe it should remove the top item from the list of copied items? Assuming that vim has one of those (in Emacs parlance it's called the kill ring).

Re: Bad NEWS, Emacs

#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 accomplishes is demonizing people who donate their time to the project. Already this thread has people saying stuff like “I don’t like this person.”

Re: Bad NEWS, Emacs

#96
post #46

Muscle memory should be elevated to a first class concern when it comes to emacs.

At a minimum switching anything that breaks muscle memory should be a toggle that defaults to "keep my config how it used to be"

Re: Bad NEWS, Emacs

#97
post #46

Muscle memory should be elevated to a first class concern when it comes to emacs.

More generally, any frequently used software should be made “muscle-memorizable”, and then should not break it in later versions without good reasons. Muscle memory has the benefit of enabling “blind” and semi-asynchronous operation of the software, without constant visual confirmation for each micro-interaction. There’s unfortunately a trend in desktop software to make operation by keyboard ever more cumbersome or outright impossible.

Re: Bad NEWS, Emacs

#98

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.

It'll take me a day or two to get used to it and then it'll be fine for me. But I only really use registers to quickly jump around in buffers. If no configuration for switching to the old behaviour makes it in before Emacs 30 is released I'd be surprised if it were to take more than a week before someone makes a package that adds the old behaviour back in.

Re: Bad NEWS, Emacs

#99

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/

Re: Bad NEWS, Emacs

#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 discussion if overwriting registers should prompt for confirmation (which it didn't use to do). Let's wait how that one turns out. I fail to see why one would need to write a long blog post and maintain a fork because of something like this... maybe just wait it out a bit and let people voice their opinions, it takes a bit of time...
Post reply on HN