Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>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 original thing they are upset about probably would have happened, per your own description of the process.

I saw a very similar process unfold with clojure-mode, where rms floated the idea of rewriting it and taking control of the name from the original longtime author, a Clojure community member. The reason this didn’t happen is people got upset and posted to the list - but those very people who caused it not to happen were told they were blowing things out of proportion. So that doesn’t seem like a very meaningful criticism.




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 that it's the thing he wants (and Emacs does now). A lot of his upset seems not to be about the idea of an option to support the new behavior (which he wrote a patch to support!), but about the attitude with which this was introduced. In return, he's coming at this issue with an attitude that seemed fit to match what he thinks the maintainers are bringing.

So that's why it's important to ask if this blog post has misunderstood the arc of changes to Emacs. If the pushback will probably result in the current default staying in the editor. Because assuming the old behavior is best, even though some maintainers like the new behavior, is just as high handed as forcing the new behavior.


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.


Here is the recap of someone is interested https://metaredux.com/posts/2023/09/09/clojure-support-in-em...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: