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…
Bad NEWS, Emacs
91–100 of 250 posts
Re: Bad NEWS, Emacs
#92It 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…
Re: Bad NEWS, Emacs
#93I'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…
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
#94Earlier 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.
Re: Bad NEWS, Emacs
#95I 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
#96Muscle memory should be elevated to a first class concern when it comes to emacs.
Re: Bad NEWS, Emacs
#97Muscle memory should be elevated to a first class concern when it comes to emacs.
Re: Bad NEWS, Emacs
#98This 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.
Re: Bad NEWS, Emacs
#99Reviewing 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…