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

201–210 of 250 posts

Re: Bad NEWS, Emacs

#201

Post by Exuma »

ramses0 wrote: post #165
Exuma wrote: post #101

Earlier quoted context omitted.

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.

"ayy - copy function signature "byy - copy return signature "ap "bp - paste either... :reg - show all registers "3p - paste 3rd "historical" register "_dd - delete into the /dev/null buffer (so you don't eat your `yy` register that you'd already yanked) It's admittedly a bit of an advanced/esoteric feature, but being able to paste "this part" or "that part" being somewhat context dependent is useful. Also useful in t…

Ah this is incredible, thank you. I didnt realize that about ... wow, that is crazy cool.

Next question, do you usually add stuff to buffers in alphabetical order... a,b,c or do you pick something easier within reach like a,s,d (or something else entirely)

Re: Bad NEWS, Emacs

#202

Post by Ferret7446 »

tarsius wrote: post #110

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

I disagree. The Emacs community has, at least historically, strongly valued backward compatibility. Breaking existing users is just about the worst thing you could do in Emacs.

If we aren't strongly considering reverting a breaking change immediately, that signals that the Emacs devs no longer value backward compatibility as highly, which means Emacs is abandoning many of its existing users.

https://www.murilopereira.com/the-values-of-emacs-the-neovim...

Core values matter. The Emacs maintainers did something that violated a core value, and the community is rightfully offended.

Re: Bad NEWS, Emacs

#203

Post by JoeyBananas »

The tone of this author... Very... "neckbeard"-esque. This is an incredibly obscure feature only 3 nerds use, not the the Immovable Ladder of the Church of the Holy Sepulcher. The fact that some unpaid maintainer changed it slightly without consulting you first does not necessarily constitute "breaking master." It's master we're talking about, not stable or a tagged release. Good god.

Re: Bad NEWS, Emacs

#204

Post by uranusjr »

achikin wrote: post #197
yaantc wrote: post #178

Earlier quoted context omitted.

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?

Because merging into main better exposes the proposal to a more diverse crowd and attracts needed feedback. Especially when you’re managing multiple proposed features, it’s not viable for a mass of users to check out and test those from their individual branches. Without merging fast, you can only gather opinions from people actively reviewing patches, which are a far more minority group and likely to be biased.

Re: Bad NEWS, Emacs

#205

Post by BaculumMeumEst »

layer8 wrote: post #102
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”.

This article is accusing maintainers of pushing a bad change. It was immediately obvious that there was only one side of the story being told here. And lo and behold, there was a lot of missing context:

https://news.ycombinator.com/reply?id=38592984&goto=item%3Fi...

and individuals involved have been receiving harassment:

https://www.reddit.com/r/emacs/comments/18f5oi9/comment/kcss...

Re: Bad NEWS, Emacs

#206

Post by rightbyte »

smarx007 wrote: post #119

I am sorry but this whole post seems like gaslighting. Looks like maintainers welcomed a patch bringing the old behaviour behind a flag [1]. Eshel Yaron then writes "Sure. I'm attaching two patches", while doing the exact opposite of what was asked, namely undoing the commit that has already landed on the main branch and introducing merely parts [2] of the new behaviour behind the flag. It's totally fine to disagree…

I like how RMS pops up and complains about a Github link requiring non-free software and then returns to what ever he was doing.

Re: Bad NEWS, Emacs

#207

Post by kazinator »

yaantc wrote: post #144
tarsius wrote: post #110

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

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…

> If you use the development branch, you can't raise hell when there's a breaking change: it's to be expected!

If nobody raises hell on a development branch, the change will have a way of making it to the master branch.

Re: Bad NEWS, Emacs

#208

Post by kazinator »

tarsius wrote: post #110

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

In my organization (embedded development in VOIP area) we revert breaking changes immediately, as soon as the breakage is identified.

Also, same in every company I've ever worked in that had any kind of process.

Re: Bad NEWS, Emacs

#209

Post by ramses0 »

Exuma wrote: post #201
ramses0 wrote: post #165

Earlier quoted context omitted.

"ayy - copy function signature "byy - copy return signature "ap "bp - paste either... :reg - show all registers "3p - paste 3rd "historical" register "_dd - delete into the /dev/null buffer (so you don't eat your `yy` register that you'd already yanked) It's admittedly a bit of an advanced/esoteric feature, but being able to paste "this part" or "that part" being somewhat context dependent is useful. Also useful in t…

Ah this is incredible, thank you. I didnt realize that about ... wow, that is crazy cool. Next question, do you usually add stuff to buffers in alphabetical order... a,b,c or do you pick something easier within reach like a,s,d (or something else entirely)

Usually a/b/c but sometimes f/function, k/key, v/value... just a simple mnemonic.

To really blow your mind:

    i%

    V:!ls
Then you start playing with marks a little bit with a similar concept (eg: ma, mb, mc, 'a, 'b, 'c), and the good friend `gi` (go back to previous insert position)...

It's again, esoteric, but as you use it more, it becomes less esoteric and more just another part of your vim vocabulary (:help search-offset, fellow traveler).

Re: Bad NEWS, Emacs

#210

Post by kazinator »

jbluepolarbear wrote: post #136
tarsius wrote: post #110

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

That’s a bad process. The review of the feature should start before it’s merged into main branch, not after. It totally reasonable for people to be upset with a breaking feature in main branch without discussing it with the community at large. Changes merged in like this are how long standing tool lose community support.

On the job, I wouldn't go implementing whatever pops into my head without input from my manager and product management.

Even if the change could easily pass a technical review and get merged.

First you have to determine: do we need this for the product? If this change is made, does it break user workflows? What difficulties will users have if they pick up this change?

Post reply on HN