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

211–220 of 250 posts

Re: Bad NEWS, Emacs

#211

Post by kazinator »

yaantc wrote: post #153
jbluepolarbear wrote: post #143

Earlier quoted context omitted.

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

The article is just his author view. Please read the emacs mailing list threads to get the full picture. GP is correct, and this is quite normal: some people using Emacs master will not follow all the mailing list discussions and commits. So they will notice a change only after it is merged. Nothing wrong with this, and nothing wrong with being unhappy about such a change. What's wrong in my book is the nature of the…

Then there are people who don't follow master.

Some people only pick up releases, including test releases.

Some people only work with final releases.

All those people could find something suddenly not working well.

Re: Bad NEWS, Emacs

#212

Post by kazinator »

tsimionescu wrote: post #147
mixedmath wrote: post #33

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…

> The author of this article came along, ...

You mean, "luckily for the entire fucking Emacs community, one of the small number of people who pick up unreleased master commits came along and happens to be a user of registers ..."

Re: Bad NEWS, Emacs

#213

Post by shadowgovt »

travisjungroth wrote: post #193
shadowgovt wrote: post #151

Earlier quoted context omitted.

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.

Well the good news is it should be straightforward to customize the old behavior back for people who don't like the trade-off.

Re: Bad NEWS, Emacs

#214

Post by ChrisMarshallNY »

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…

> gee there sure are a lot of stubborn people on emacs-[%]

I have been watching Emacs vs Vi wars for decades. People take this stuff seriously.

In my case, I tend to use GUI editors, whenever possible (or Nano/Pico, if absolutely forced to). I know, I know, I'm a wimp. Guilty as charged.

Re: Bad NEWS, Emacs

#215

Post by Kalq »

kazinator wrote: post #211
yaantc wrote: post #153

Earlier quoted context omitted.

The article is just his author view. Please read the emacs mailing list threads to get the full picture. GP is correct, and this is quite normal: some people using Emacs master will not follow all the mailing list discussions and commits. So they will notice a change only after it is merged. Nothing wrong with this, and nothing wrong with being unhappy about such a change. What's wrong in my book is the nature of the…

Then there are people who don't follow master. Some people only pick up releases, including test releases. Some people only work with final releases. All those people could find something suddenly not working well.

If you are this hypersensitive to change, it behooves you stay on a stable release and only upgrade after you've read the CHANGELOG and NEWS files.

Re: Bad NEWS, Emacs

#216

Post by Kalq »

lvncelot wrote: post #82
isodev wrote: post #19

Earlier quoted context omitted.

I’m not an Emacs user and also failed to understand what went wrong. So they changed a default shortcut or something?

Imagine copying via Ctrl-C and having to hit enter to confirm a dialog "Did you want to copy this text". It's added, unavoidable friction for an action that some people use a lot . Additionally, some actions on top of the original behavior (that depended on Ctrl-C completing automatically, to keep with the analogy), now are just broken.

While I appreciate the analogy, it's important to note that registers are a fairly advanced feature, not quite as ubiquitous as Ctrl-C. Standard Emacs copy-paste remains unchanged and functions just as expected.

Re: Bad NEWS, Emacs

#217

Post by travisjungroth »

shadowgovt wrote: post #213
travisjungroth wrote: post #193

Earlier quoted context omitted.

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.

Well the good news is it should be straightforward to customize the old behavior back for people who don't like the trade-off.

It should be, but the change didn’t have it as a setting.

Re: Bad NEWS, Emacs

#218

Post by kazinator »

Kalq wrote: post #215
kazinator wrote: post #211

Earlier quoted context omitted.

Then there are people who don't follow master. Some people only pick up releases, including test releases. Some people only work with final releases. All those people could find something suddenly not working well.

If you are this hypersensitive to change, it behooves you stay on a stable release and only upgrade after you've read the CHANGELOG and NEWS files.

Someone hypersensitive to changes track changes as early as possible, and complain quickly and loudly.

Those who are not sensitive changes just use whatever Ubuntu (or whatever) provides and are unconcerned with the development.

Re: Bad NEWS, Emacs

#219

Post by tsimionescu »

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?

What kind of time? It spent around two months between the first proposal and being merged. Do you think that people would have trawled through the mailing lists and found this and given their reviews if only it had been given 1 more week?

Ultimately, the consequences of a patch, especially one that changes UX, can only really be evaluated after the community starts using it. People using the master branch of Emacs are basically those who wish to work as the QA engineers of Emacs. End-users use release branches or even pre-packaged releases from their distro.

So, the normal process for a UX change is to merge it to master in order to get comments on the impact. Based on comments, you can either revert, move behind a flag, etc.

Re: Bad NEWS, Emacs

#220

Post by tsimionescu »

kazinator wrote: post #210
jbluepolarbear wrote: post #136

Earlier quoted context omitted.

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?

Emacs is a community-driven project. And the author of this patch identified several issues with the feature, created a fix, proposed it for review, debated the impact with other devs on the mailing list for weeks, addressed all concerns raised, and then finally other more senior devs merged the change to master, where all new unstable changes go.

Then, people who agree to test out all changes to Emacs by using the head of master found, basically the QA department of Emacs, came back with feedback that they like some of the improvements, but that they don't like one particular aspect (the extra RET). Thierry started addressing them, and a setting to disable the feature was added - but the initial version missed the mark. The article author also was part of this process, and even proposed a patch, but their attitude made others ignore it after the initial review (their patch reverted all changes and only implemented a tiny subset of the original, behind the discussed flag).

Post reply on HN