So, what's the "other side's" argument in this? Usually these opinionated changes come with some level-headed reasoning behind the changes. Or maybe not?
Bad NEWS, Emacs
191–200 of 250 posts
Re: Bad NEWS, Emacs
#192I'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…
> 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.
With paste you can see what got pasted, so you've got a chance to realize it is not what you wanted.
But how about for copy? If you meant to copy into register 'r' but missed by a key and typed 't' would it be noticeable right away?
I don't use Emacs so don't know how its undo works, but when I use named registers in Vim it is often to hold something that I'm not going to paste for quite a while. By the time I notice the error it would be annoying to undo all the way back to the mis-copy.
If copying into the wrong register was common enough to need to be addressed, my first thought would be something like adding a status message pups up for a short time near the cursor that says something like "Copied to 't'".
Re: Bad NEWS, Emacs
#193Earlier quoted context omitted.
This is equivocating. It’s not better for purely historical reasons, it’s just a bad trade of speed for accuracy. If you really want to be sure, is one return click enough? Maybe it should be two. Maybe a mouse click. You could throw in a five second cool down to be really sure. Obviously some of these ideas are worse than the status quo.
I don't dispute that two or more clicks or a mouse press would be a bad trade-off of speed for accuracy. Why is one press of the enter key a bad trade-off of speed and accuracy besides "It's never been that way before?"
These are high speed actions and usually all home-row. The return hit increases the time a significant percentage. They’re also easily undone, so the cost of mistakes is low.
Imagine needing to hit return every time you ctrl-v. Really no point when ctrl-z is available.
Re: Bad NEWS, Emacs
#194It 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 get it; this is maybe to please the newer/younger crowd This seems to miss the point of these changes. If you're only concerned with your own workflow then almost any changes that you didn't specifically request are annoying. However, if you're concerned with the continued development/relevance of the program then it becomes clear that change must occur. Taking into account both existing user's concerns and barri…
Why should catering to non-users even be a concern? It is like these radio stations and tv channels that blend into the sameness blurb.
If the last emacs user press C-x C-c for the last time in whatever years that is not a failure.
Re: Bad NEWS, Emacs
#195I'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…
> 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. In particular, the universal Emacs cancel key, C-g, would not work here: instead, the text or position would be saved to a register called ^g
I'm not very familiar with Emacs, so possibly stupid questions incoming.
If you start to type C-x r SPC t to save to register t, does C-g work right after the C-X and the r?
If so is that because the C-x, r, and SPC are part of the command sequence whereas the t is just an argument used by the command, and the C-g handling is done in the command sequence processing?
Emacs is pretty famous for its flexibility in letting users bind and unbind key sequences to commands. Could people who like the old behavior fairly easily effectively restore it by unbinding the handler for C-x r SPC, and then bind handlers for C-x r SPC a, C-x r SPC b, C-X r SPC c, and so on for all registers they want to use, with each of those handlers just copying to the appropriate register?
That should let them use the same keystrokes they now use, and if my guess above about C-g handling is right also make C-g work to cancel after C-x r SPC.
Re: Bad NEWS, Emacs
#196Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.
You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.
No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.
Re: Bad NEWS, Emacs
#197Earlier quoted context omitted.
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's a misunderstanding here: I'm not saying "don't complain". Complaining in itself is fine, and others are complaining on this topic in a way that looks OK to me (and will probably be more efficient too). It's the nature of this specific article complaint that I have a problem with. I agree with @tarsius on this: just give the discussion (and patches) some more time, and it's likely to end just OK from past expe…
I wonder why wasn’t this patch given time before merging it? Isn’t that the whole purpose of patches and merge process?
Re: Bad NEWS, Emacs
#198When 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…
Here is the recap of someone is interested https://metaredux.com/posts/2023/09/09/clojure-support-in-em...
Re: Bad NEWS, Emacs
#199I 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…
The actual reasonable approach would be to implement it as a strictly opt-in feature for the next release and then when many people have tested it, gather some some usage data and then decide on whether to make it the new default behavior or not.
Just breaking established user behavior and muscle memory just because you think something might be better without having gathered any actual evidence is insane.
Re: Bad NEWS, Emacs
#200Maybe 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 discussi…
Context: I'm an Emacs user for 20 years...
> There was a change committed which made using registers more friendly to use for newbies.
...and didn't realize this feature existed.
> Maybe let's keep the drama down a bit?
Agreed, this is non-news.