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

221–230 of 250 posts

Re: Bad NEWS, Emacs

#221

Post by tsimionescu »

rightbyte wrote: post #159
jeremyjh wrote: post #134

Earlier quoted context omitted.

> So I think this has been blown way out of proportion. If this has happened as described in the OP then I’m worried about the health of emacs. There was controversy before it was merged to master, and they merged it anyway. Breaking user workflows and not even making it optional, much less opt-in comes across as a callous disregard for user experience.

Ye once the devs go user hostile it is all down hill from there. Especially in a project like Emacs, where every efficinado has their own really custom config. I mean, reading the Emacs docs it is written in a way that make you feel like color display and a mouse is cutting edge hardware and optional. It is a very conservative project ...

But that is not what happened. The author of this article is misrepresenting the attitude of everyone involved. There was a single reviewer who noticed the patch and started engaging with it, Michael, and while he originally raised the concern quoted in the article, he discussed with the patch author and they finally got to a common ground, he suggested several other improvements that the patch author worked on, and finally he is the one who approved the patch to move further - in a process that took almost two months.

This is not to say that both the patch author and the reviewer didn't misjudge the importance of a workflow change. But no one was being hostile or dismissive - they discussed the issue, and concluded (probably wrongly) that the new behavior is overall better and wouldn't significantly impact anyone negatively.

Then, two days after it became available, other users started seeing it and raised bugs on the behavior, which the patch contributor started addressing. The author of this article was the first one to raise such an issue, and it wasn't initially clear how many others would agree with them. Still, the maintainers and the patch author agreed immediately that a flag to re-enable the old behavior would be a good thing, and asked if the article author would like to contribute it (the patch author wanted a break from this feature that they'd worked for weeks on). The article author came back with a patch that reverted all of the changes made by the original patch except for one. When told about this, they said that they only kept the changes that had any value, and that they'd require proof the other changes are also useful before going further - to which they didn't receive any more replies, for obvious attitude reasons.

Re: Bad NEWS, Emacs

#222

Post by tsimionescu »

timmytokyo wrote: post #183
tsimionescu wrote: post #163

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…

>The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself. Regardless of the reasons for the change, a single author was permitted to commit a change that broke the workflows of potentially thousands of users. And there was no way users could work around it to maintain their previous workflows. That sounds arrogant and annoying.

That is how all changes work, especially for an editor like Emacs where the internal APIs are public. As far as I understand, the accepted workflow for Emacs dev is:

1. Raise an issue through the mailing list.

2. Propose a patch on the mailing list

3. Maintainers send review comments about the patch.

4. The patch gets rejected or merged to master

5. The few people using head of master give feedback about the change

6. The change gets modified or reverted

7. A release branch is created from head of master

8. The bigger group of people who use un-released Emacs release branches start giving their feedback

9. More fixes are made on the release branch. Some features get reverted entirely.

10. A new Emacs release is decided and published

11. The larger emacs community starts using the brand new release and filing bugs and giving feedback

12. Release patches are sometimes issued, and other feedback is taken into consideration for the next release

13. After some minor releases, major Linux distributions start packaging the Emacs release to include in their official repos

14. Only now do the majority of Emacs users actually start using the new release, with all patches and feedback addressed.

In the case of this change, it has just made it at step 5 three days ago, and it is now in step 6. There is a LONG way to go before it makes it to any significant number of Emacs users. I actually doubt that there are thousands of users using head of master at all - out of which only a subset probably use registers in any way to begin with.

Personally, I've been using Emacs for 5+ years in my day to day job, and I am at a point where I build my own Emacs binaries. Even so, I'm only doing this from the latest release branch, and only close to a release, I don't have the energy to deal with the potentially broken head of a new release, even less so head of master.

Re: Bad NEWS, Emacs

#223

Post by tsimionescu »

kazinator wrote: post #212
tsimionescu wrote: post #147

Earlier quoted context omitted.

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 ..."

Actually multiple people have complained, some less hyperbolically than this author. And, unless you think the people who build their own Emacs from head of master are less likely to use more obscure features of Emacs, then this feedback was always going to come before anything that actually hurts the Emacs community made it even close to a release.

Re: Bad NEWS, Emacs

#224

Post by lelanthran »

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…

> Thierry started working on a new improvement to create a flag that keeps both all of his new work, but allows the previous workflow too (particularly, removing the extra RET, which was ultimately a side effect, not the main point). The patch missed the mark, but it is still being worked on.

I think that if the author of this rant did not come along and rant, there would be no "but is still being worked on" done. My reading is that the maintainer (Theirry) was happy with the extra RET.

NOW it is getting worked on because of the dogged and emotional criticism by the rant's author, prior to him writing his rant.

If he didn't make such an emotionally charged and disruptive arguments and patches, the rest of us poor Emacs users would have only found out about the broken workflow (extra RET) once the bug was fully baked in, requiring waiting for the next release in order to get a fix.

Re: Bad NEWS, Emacs

#225

Post by domq »

samus wrote: post #128
binary132 wrote: post #63

Obviously the only possible solution is to attempt another fork/reimplementation of emacs. This one will definitely win and not be totally irrelevant like all the others.

The impact of these forks is that the community around the main project is slowly eroded. But it doesn't really matter whether the fork brings the main project to the negotiation table. The author of TA is able and is committed to carry and maintain that patch in his local repository until the end of time. What is missing to complete such a fork is publishing that local repository.

I have a hard time putting faith in that “balkanization theory” from the '90s anymore. A fork gains traction if and only if it manages to get ahead of the mainline feature-wise, and stay there, by a sufficiently wide margin for customers to overcome their inertia. We'll see whether this ~eshel person manages to pull that off, or not (my money is on “not”.)

Re: Bad NEWS, Emacs

#226

Post by domq »

CoastalCoder wrote: post #77
binary132 wrote: post #63

Obviously the only possible solution is to attempt another fork/reimplementation of emacs. This one will definitely win and not be totally irrelevant like all the others.

From the blog post, I couldn't really tell what the author's long term intentions were for his fork. Maybe just to persuade the mainline maintainers?

Forking Emacs on such grounds is a symptom of ego malfunction. The proper step (after diplomacy has failed, which it hasn't yet in this instance) is to author an alternate implementation of the feature in Emacs Lisp and publish it.

Re: Bad NEWS, Emacs

#227

Post by domq »

lstodd wrote: post #72
blantonl wrote: post #56

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?

Yeah, sure. People tried for years to extract the reasoning behind Gnome 2 to Gnome 3 changes and still no one has any idea. Almost as it's just and only petty power trips.

The “or maybe not?” part of the message you are replying to, tells me that someone got told.

Re: Bad NEWS, Emacs

#228

Post by domq »

sgbeal wrote: post #47
pilgrim0 wrote: post #14

I don’t fully understand the nature/impact of the change but this conflict seems so minor to me. Like, people on both sides display the same level of entitlement but for different reasons, and they all think they have their are “right”. Hum, no, for outsiders you all appear stubborn and lacking ability to compromise. “Oh my gosh, I’ll have to press 1 extra key now, this project is doomed!”, “no no no, this little cha…

> “Oh my gosh, I’ll have to press 1 extra key now ... " is a genuine usability tragedy for folks who have 25+ years of muscle memory involved. There are no small number of emacs users, myself included, who fall into that category. > "... this project is doomed!” obviously it's not quite that bad, but any change to long-standing muscle memory is going to send countless users down a rabbit hole looking to undo that cha…

That is a correct and fair assessment of the impact, assuming the change lands in a release as-is (which apparently it won't: https://lists.gnu.org/archive/html/emacs-devel/2023-12/msg00... )

Re: Bad NEWS, Emacs

#229

Post by domq »

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…

This is basically the only reply that everyone on this thread should read. Thanks for your research.

Re: Bad NEWS, Emacs

#230

Post by kazinator »

pilgrim0 wrote: post #14

I don’t fully understand the nature/impact of the change but this conflict seems so minor to me. Like, people on both sides display the same level of entitlement but for different reasons, and they all think they have their are “right”. Hum, no, for outsiders you all appear stubborn and lacking ability to compromise. “Oh my gosh, I’ll have to press 1 extra key now, this project is doomed!”, “no no no, this little cha…

Would a guitarist be wrong to reject an instrument whose string had to be plucked twice before starting to vibrate?
Post reply on HN