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

231–240 of 250 posts

Re: Bad NEWS, Emacs

#231

Post by prmoustache »

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.

> And there was no way users could work around it to maintain their previous workflows.

Yes there was. Staying on version 29 of emacs. Or write everything that is needed in lisp to revert to old behavior.

Re: Bad NEWS, Emacs

#232

Post by Jochim »

rightbyte wrote: post #194
Jochim wrote: post #129

Earlier quoted context omitted.

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

Where do users come from? People trying out the software and enjoying it. I'm quite glad that the emacs maintainers care about this, as I'm sure I've benefitted greatly from the contributions some of those people will have made.

Improving things that put new users off is often the same as improving things that annoy existing users. Keeping the spirit of the tool intact doesn't require doing everything the same way.

> If the last emacs user press C-x C-c for the last time in whatever years that is not a failure.

I disagree. It'd be just as much of a failure as emacs moving away from it's focus on extensibility/configurability. It's meant to be a useful tool, if no-one is interested in using it, then it has most likely failed at it's purpose.

On the current situation, after reading through the emacs-devel mailing list, it becomes clear that the author of this change - a long term user and contributor - was attempting to address an issue that had come up in his own workflow. He seemed interested in engaging with people who had concerns surrounding the change. The tone of the article is honestly embarrassing in comparison.

Re: Bad NEWS, Emacs

#233

Post by stjohnswarts »

atticora wrote: post #75
krmboya wrote: post #46

Muscle memory should be elevated to a first class concern when it comes to emacs.

Once a new version of my favorite file manager came out with remapped key bindings. I can't even remember the name of it now. But my own anger was memorable as totally out of proportion even when I was feeling it. My investment in muscle memory had been trashed! I thought several evil thoughts before calming down. So while it sounds trivial I can understand why the reaction to the crime of Betrayal of Muscle Memory h…

and most times it's not really any value added; it's something lame like "this other popular product does it this way" or "industry standard" or "our human optimization team found this was better" and give the middle finger to previous users. It happens with all interfaces, but people look to stuff like emacs and vim to be better than that

Re: Bad NEWS, Emacs

#234

Post by stjohnswarts »

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.

Gnome developers gave pretty thorough reasons why they made certain changes in UI and code design, or was I hallucinating that period of my life? I mean, just because one doesn't like designers' choices doesn't equate to "couldn't extract reasoning". Also, it's their project, and I hate that they ignored the user community it still fell under their authority to do it and let users decide if they would tolerate it or move to a different windowing system. Personally I just moved back to KDE and have stayed there, other than very limited resource systems where I use lxde or just straight terminal+tmux.

Re: Bad NEWS, Emacs

#235

Post by ParetoOptimal »

bachmeier wrote: post #132
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…

It would make a lot more sense to have a discussion before breaking long-used behavior. I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.

> I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.

For me, emacs developers breaks things for users the least and highly value backwards compatibility.

Re: Bad NEWS, Emacs

#236

Post by ParetoOptimal »

tzs wrote: post #192
ekidd wrote: post #104

Earlier quoted context omitted.

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…

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

Hm, I use consult-yank for this and order less search things I've yanked (copied).

I suppose registers could be more efficient if you copy a lot making narrowing more difficult.

Re: Bad NEWS, Emacs

#237

Post by kazinator »

tsimionescu wrote: post #220
kazinator wrote: post #210

Earlier quoted context omitted.

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

I've now read (or at least skimmed) this in it entirety:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394

Thierry opened this as a simple bug, but then implemented something with multiple enhancements rather than addressing the bug, while causing UX regressions.

It looks like only one developer was engaging the content, a Michael H., and he pointed out early, as far back as in October, both the problems that Eschel later latched onto.

Eschel came up with a patch that just addresses #66394 in a small way.

The reply to that was:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394#201

"But your patch only fixes this bug, reverting half a dozen features mine adds."

Using a bug ticket as a vector for introducing enhancements is a software engineering no-no.

They should merge the simplest patch that closes the bug without regressing anything or introducing extraneous enhancements. For those, a new enhancement ticket should be opened.

If Eschel's patch can close #66394, and not break anything, the consideration of that it doesn't implement another solution's enhancements is actually a plus.

There is possibly another bug ticket hiding in there based on the remark [y]ou reintroduced the old implementation which was not wrote correctly about handling various keys, particularly C-g. Existing behavior of not correctly handling various keys sounds like a problem different from the 66394 issue.

If the project doesn't want the simplest fix for an issue, but to address something architectural, like with a view for adding enhancements or whatever, that can be turned into another ticket where you articulate that. The original bug can then be marked pending or blocked by that with a note that we don't fix this until that one.

Re: Bad NEWS, Emacs

#238

Post by kazinator »

tsimionescu wrote: post #223
kazinator wrote: post #212

Earlier quoted context omitted.

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

Having read/skimmed the bug I see now that the issues objected to by Eschel were all raised early, back in October, by the other developer looking at the work, Michael H. He pointed out the RET thing and the issue with using control characters as a registers.

Re: Bad NEWS, Emacs

#239

Post by gpderetta »

kazinator wrote: post #237
tsimionescu wrote: post #220

Earlier quoted context omitted.

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

I've now read (or at least skimmed) this in it entirety: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394 Thierry opened this as a simple bug, but then implemented something with multiple enhancements rather than addressing the bug, while causing UX regressions. It looks like only one developer was engaging the content, a Michael H., and he pointed out early, as far back as in October, both the problems that Esche…

Does Emacs even do enhancement tickets? It is a community driven project where people implement what they want to scratch an itch and get merged as long as they convince enough people; it is not a PM driven one with roadmaps, sprints and narrowly defined features.

Re: Bad NEWS, Emacs

#240

Post by kazinator »

aeturnum wrote: post #169
eduction wrote: post #140

Earlier quoted context omitted.

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

I think the thing being criticized is the tenor of the pushback. The suggestion that, because the blog author (Eshel Yaron)'s patch wasn't accepted and the change is still currently in, that the maintainers are "insistent not to budge" and that this "demonstrates clear disrespect for Emacs user preferences, and indeed their freedom." The Yaron's attitude seems to suggest that there's an easy right answer here and tha…

There is actually an easy answer. There is a bug:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394

The bug's description is this:

"When using `copy-to-register`, it is hard to see which register is already taken in the preview buffer."

If Eshel Yaron's simpler patch is enough to close 66394, and doesn't break anything, that should be used.

Generally speaking.

Post reply on HN