Live data from Hacker News

Bad NEWS, Emacs

eshelyaron.com

171–180 of 250 posts

Re: Bad NEWS, Emacs

#171

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…

This extra context is very informative, thanks!

Re: Bad NEWS, Emacs

#172

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.

[deleted]

Re: Bad NEWS, Emacs

#173

Earlier quoted context omitted.

The friction seemed less about the change as such as in the unilateral delivery. Even good change (whether or not this is) needs a gentle transition.

If I understood this correctly, the new behavior cannot be customized back to the old behavior. If that's true, then that's obviously very bad. Generally, as an Emacs user, I don't just want an opt-in or a gentle transition, I need to be able to customize everything to my needs.

This is Emacs, so one presumes that it's a SMOeL (Simple Matter Of eLisp) problem.

However, it seems tasteless to impose the burden.

Re: Bad NEWS, Emacs

#174
post #101

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.

Usually I yank into like p or something when I want to not just paste later, but delete something and then paste. I hate it when I delete something to make room for what I paste and it gets rid of it. Then I fumble with the numbered registers and mess it up.

Or when I select something and then paste and I actually wanted to keep my paste buffer and not replace it

Re: Bad NEWS, Emacs

#175
post #149

Earlier quoted context omitted.

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 rev…

What I read (did not verify) was that two users discussed and decided on the feature. That's hardly a well deliberated change.

I think for user facing features it makes more sense to provide new behaviors as opt-in, and go through a longer RFC period. Only if and when the new behavior is widely used and popular, then you flip the switch to default.

Re: Bad NEWS, Emacs

#176
post #113

Earlier quoted context omitted.

This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?

I use Emacs, mostly for Org Mode, but not registers. I also understand perfectly the problem, and I also can't understand the upside. The only clue I see is in the polite objection the author quotes who writes "I agree it's safer..." But I don't understand safer in what way or why 1 person gets to decide safer=better=forced.

[deleted]

Re: Bad NEWS, Emacs

#177
post #139
post #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 discussi…

No program feature should ever be designed to be "friendly to newbies". Easy to use (in general) - yes; easy to learn - yes; hard to do accidentally - yes; low friction - yes; discoverable - yes. However, designing for the person who has never learned to use the feature inevitably leads to your program having a very low skill ceiling and being a disservice to power users. Also, how do you know the new design is "frie…

> They broke their users' trust.

And now the drama is dialed to 11. I see no point in responding to such hyperbole.

Re: Bad NEWS, Emacs

#178
post #144

Earlier quoted context omitted.

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'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 experience.

Re: Bad NEWS, Emacs

#179

Earlier quoted context omitted.

The article says otherwise. It says that many concerns were disregarded during that time.

That's what the article says, but I checked the actual mailing lists. Any replies that asked for a change of this kind came in after the patch was finalized. Even this author's own complaints. And, the author in particular didn't understand, or seek to understand, why the patch was added in the first place. Instead, their proposed "fix" that they complain about in the article reverted all of the improvements the auth…

Perhaps you could mention what these improvements are or give a link to the messages you're getting this information from?

Re: Bad NEWS, Emacs

#180

Earlier quoted context omitted.

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 rev…

What I read (did not verify) was that two users discussed and decided on the feature. That's hardly a well deliberated change. I think for user facing features it makes more sense to provide new behaviors as opt-in, and go through a longer RFC period. Only if and when the new behavior is widely used and popular, then you flip the switch to default.

Can you link to what you read please
Post reply on HN