39 ms·

Bad NEWS, Emacs

357 points by amiralul 3y ago

coldtea 3y ago
[flagged]
- throwaway128376 3y ago
  [flagged]
- addicted 3y ago
  Problems with a large open source project are never about a single individual. Individuals will make mistakes and have wrong opinions. The problem here appears to lie with the larger eMacs development community.
- deleted 3y ago
  [deleted]
ur-whale 3y ago
OpenSource working as intended, no?
- mrlonglong 3y ago
  Yup. Great isn't it when the system works as intended.
- tvink 3y ago
  Sure, in the sense that they can differ and co-exist? Of course it's much better in OSS when differences can be resolved so that more people may work together on fewer forks, so discussion should come before forks most of the time. The author seems to be doing exactly the right thing - tried to contribute to the shared work, voice their concerns and thought process, and ultimately fork in protest.
- DonHopkins 3y ago
  Absolutely not! Free Software working as intended. Are you trying to trigger RMS by calling Emacs "Open Source"?
- addicted 3y ago
  Just because a system works doesn’t mean all outcomes out of the system when it’s working are equally good. Even the best working system will still require people to make good decisions to have the best outcomes.
MiddleEndian 3y ago
[flagged]
NikkiA 3y ago
Assuming any particular commit in git represents the eventual state of a release seems foolhardy.
- marcinzm 3y ago
  That's not the author's point. They did try to improve the behavior in a future commit and were shot down. Hard it seems. So were any requests from others to change this before release.
  - juped 3y ago
    [flagged]
    - deleted 3y ago
      [deleted]
  - chongli 3y ago
    Not only that, but the author of the original offending change asked the author of this blog to write a patch to make the change optional within the UI and then rejected the patch that was written. That seems like bad faith to me.
    - yaantc 3y ago
      Read the mailing list thread: the patch did much more than making the change optional, it did revert other related changes. That's why it was rejected. Other discussed changes were taken in, and it's not settled yet it seems: the discussion is on-going. I find the reporting here very one sided and uselessly dramatic. I read the thread and don't see arrogance, just (sometimes strong) differences of opinion. Calling "arrogant" anyone who don't agree and fold to your view, and create drama and draw the crowd against one specific person (the initial change author, OK, but it was done with maintainers in the loop) where the crowd won't check the details is not OK in my book.
      - 3y ago
jason_stelzer 3y ago
I have been using emacs since probably 94. This change, without a toggle from userspace to disable it is a kick in the pants. I will follow your fork until (if) they come around.
jhoechtl 3y ago
I someone is to fork Emacs its because of getting proper UI integration or multithreading. This is just a neglectable, whimsical step. Sorry. What Emacs needs is the nvim/vim Schisma.
- PaulHoule 3y ago
  There was Xemacs back in the day… and I guess it is still around.
  - medstrom 3y ago
    It's still around in the same sense that twm is still around.
- ajross 3y ago
  > What Emacs needs is the nvim/vim Schisma. It's already had like six, over the decades.
- PurpleRamen 3y ago
  There are enough unsuccessful forks of GNU Emacs. None of them get enough attention and support for whatever reason, but I guess mainly because there have no real reason to exist. Emacs devs are working diligently and improving it regularly, and there is no good and simple solution for the problems it has. There won't be any nvim/vim-like Schisma happen, unless some super-dev appears who can outsmart the whole community and it's devs. Maybe, in a decade when AI become good enough and someone feeds Emacs to electron or something like that.
devnull3 3y ago
I am a Vim guy. Can someone explain what exactly is broken?
- Narishma 3y ago
  It's explained in the article.
  - isodev 3y ago
    I’m not an Emacs user and also failed to understand what went wrong. So they changed a default shortcut or something?
    - doix 3y ago
      I also don't really use emacs. But by the sounds of it, when you want to use a command that involves a register, you get a mini-popup where you input the register you want. The downside is that you must push enter after you enter the register you want.
    - lvncelot 3y ago
      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.
      - Kalq 3y ago
        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.
  - devnull3 3y ago
    I could not understand and hence I asked the question. The thing I understood was that this broke some peoples flow.
ajross 3y ago
It's a good rant, but it probably doesn't help its case that it doesn't stop to explain what the feature it's talking about actually is. Emacs registers are a really, really old abstraction. Registers are like separate clipboards, you can put stuff there and pull it out. And there are 62 of them (each associated with a core ASCII symbol: [a-zA-Z0-9]), giving you a lot of flexibilty and a very quick keyboard interface for acting on/with them. And you can even do fun stuff like execute a keyboard macro out of a register. Some people use them heavily. I don't. Anyway the author is peeved that they changed the default bindings such that there's a modal UI in the way of what used to be a fully-keyboard/home-row operation. It sounds like a reasonable complaint; I'd be annoyed too if they changed something that lived in my muscle memory like this kind of feature does.
- tinus_hn 3y ago
  ‘Default bindings’ sounds like it’s configurable to be different. Is it?
  - jsw97 3y ago
    It is not. That approach was tried and rejected, hence the problem.
    - morelisp 3y ago
      In the interest of fairness, it should be noted a very specific solution was tried and rejected (providing configuration variables to adjust the behavior of `register-read-with-preview`). I personally don't see anything preventing users from configuring alternate commands which call directly `set-register` and mapping those as they please, so in that sense it is still configurable. And in the extreme case you could even use advices, etc. It is very difficult to make something non-configurable in Emacs and I don't see the register system being so ingrained as to be one of those things. Whether it's a good idea... well, I don't use registers but the whole thing seems like a bad idea to me. I don't think I know anyone who uses registers and would like the new behavior. (But I also understand the desire to modernize `register-read-with-preview` a bit. A better solution seems like it would be providing multiple implementations so users can do the register equivalent of `(fset #'yes-or-no-p #'y-or-n-p)` like every old Emacs user does today.)
pilgrim0 3y ago
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 change is the hallmark of security, it should be mandatory for every user”. Come on…
- janice1999 3y ago
  I disagree. As a developer I think breaking literally decades old workflows for users without notice or any level of concern is a bad thing. For a program with users so reliant on muscle memory, I think the impact is far worse.
  - smitty1e 3y ago
    The friction seemed less about the change as such as in the unilateral delivery. Even good change (whether or not this is) needs a gentle transition.
    - jonathanstrange 3y ago
      If I understood this correctly, the new behavior cannot be customized back to the old behavior. If that's true, then that's obviously very bad. Generally, as an Emacs user, I don't just want an opt-in or a gentle transition, I need to be able to customize everything to my needs.
      - smitty1e 3y ago
        This is Emacs, so one presumes that it's a SMOeL (Simple Matter Of eLisp) problem. However, it seems tasteless to impose the burden.
- potatopatch 3y ago
  Inventing new things who cares, but for existing key sequences its a problem even if the new sequence would have been better. Imagine when some of these soft cars start adding power steering in an overnight update.
entropie 3y ago
> Since then, another bug report came in from a Emacs master branch user that suffered from one of the consequences of this change (a specific regression that I spelled out days before, but was ignored, for some reason), and several users reached out to the Emacs development in request to restore the previous behavior in an ongoing thread titled “Please, Restore Previous Behavior for jump-to-register”. Astonishingly, Eli and Thierry won’t seem to budge, and Emacs 30 will thus likely suck. Seriously, this is kind of funny. I use emacs for like two decades now and I knew about jump-to-register but never actively used it. But yes - emacs 30 will be bad because of this change. Barely useable anymore. This guys in their mailinglist have... very specific problems. You heard it first here. Emacs 30 will suck. Also; https://xkcd.com/1172/ https://xkcd.com/1172/ hits the spot and is - what a coincidence - about emacs and workflows.
- kyrra 3y ago
  While I understand your point, emacs is changing very specific behavior, that was intended, to do something new now. So I would say you're xkcd comment is slightly off.
  - entropie 3y ago
    > emacs is changing very specific behavior, that was intended, to do something new now No? It changes how an existing command behaves. > This commit crippled all user interaction with Emacs registers, turning commands such as C-x r s, once smooth and frictionless, into a cumbersome and painful mess. Concretely, instead of just typing the key for the register you want to operate on, you now get a fully blown minibuffer for inserting a single key.
    - broscillator 3y ago
      with all due respect c-x r s sounds far from smooth and frictionless to me
      - monsieurbanana 3y ago
juped 3y ago
This is really polemically overstating the case, but at least it links to the mailing list threads where you can see what's actually going on. Not that anyone will click them.
mixedmath 3y ago
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 easily configuring this away). Further, this happened without much discussion. Let's state a vim analogy. If I want to copy the current line into my `d` register, I can type `"dyy`. This proposal would do something like, after typing `"dyy`, open up a scratch buffer that tells the user the text and the buffer, requiring a keystroke to close. This is terrible for people who understand registers (the typical vim user). But I acknowledge that sometimes I don't copy the intended text into registers and have to try again. I also know many vim people who only yank from visual mode, which has a similar show-explicitly-what-is-being-copied behavior. The rest of this article is a description of how the OP tried to raise discussion, but the commit-author, Thierry, shot it down. Implicitly the rest of the emacs dev community is at fault too.
- Zelphyr 3y ago
  I just learned a new feature of Vim. Thank you!
  - motoboi 3y ago
    vimtutor is absolutely worth the time
    - xhevahir 3y ago
      I don't think that feature is covered in vimtutor. As far as I can tell vimtutor mentions registers only once in passing and buffers not at all.
- CoastalCoder 3y ago
  As a perpetually novice vim user, I actually would have expected "dyy" to mean Delete the current line. But that probably just proves my novice status.
krmboya 3y ago
Muscle memory should be elevated to a first class concern when it comes to emacs.
- atticora 3y ago
  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 has escalated to "fork you".
  - stjohnswarts 3y ago
    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
- bradleyjg 3y ago
  Not just emacs. I don’t care about emacs at all. What makes this story important is pointing out the arrogance of devs that love to “improve” things without any regard for people’s settled expectations. That applies as much to google maps or iOS as it does to emacs.
- runevault 3y ago
  At a minimum switching anything that breaks muscle memory should be a toggle that defaults to "keep my config how it used to be"
- layer8 3y ago
  More generally, any frequently used software should be made “muscle-memorizable”, and then should not break it in later versions without good reasons. Muscle memory has the benefit of enabling “blind” and semi-asynchronous operation of the software, without constant visual confirmation for each micro-interaction. There’s unfortunately a trend in desktop software to make operation by keyboard ever more cumbersome or outright impossible.
blantonl 3y ago
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?
- morelisp 3y ago
  I imagine it's that reading user input through something other than the minibuffer is annoying, because if you have customized your input/editing keys, read-key generally won't reflect that.
- lvncelot 3y ago
  This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?
  - rjzzleep 3y ago
    Attracting new users for with the old behaviour is too complex maybe?
    - dromtrund 3y ago
      Isn't named registers an advanced enough feature that it shouldn't be optimized for new users?
    - samus 3y ago
      The new behavior doesn't make me want to invest effort in learning registers. A notification in the status bar which register just got filled would be all I want.
    - mahkoh 3y ago
      I believe Mozilla has been successful with a similar strategy.
  - vcg3rd 3y ago
    I use Emacs, mostly for Org Mode, but not registers. I also understand perfectly the problem, and I also can't understand the upside. The only clue I see is in the polite objection the author quotes who writes "I agree it's safer..." But I don't understand safer in what way or why 1 person gets to decide safer=better=forced.
mynegation 3y ago
It’s been 20 years since I left Emacs, but I understand that this change is pretty disruptive. What I do not understand is why Emacs that prides itself in being the “kitchen sink” did not add an option to revert to the old behaviour.
- tsimionescu 3y ago
  They are adding it, most likely. The author of this article is just mad that they didn't accept their patch (which added a flag but also did away with all the other improvements).
binary132 3y ago
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.
- CoastalCoder 3y ago
  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?
  - domq 3y ago
    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.
    - kazinator 3y ago
      Your alternate implementation would have to monkey patch the shipped code. That is a fork in disguise. Not to repeat myself: https://news.ycombinator.com/item?id=38604600 https://news.ycombinator.com/item?id=38604600 The easiest way to produce a monkey patch for Emacs which reverts some behavior would be to maintain your own private fork of the repo, where you do a proper job of rebasing, resolving conflicts and validating. Then from that you take the necessary files (all the files that are different from upstream) and produce the hot-load that can be distributed to people. But, totally not a fork, man!
- samus 3y ago
  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.
wavemode 3y ago
This thread is mostly "I don't use this feature of Emacs (or Emacs at all) therefore this isn't a real problem, so stop complaining." Poor to see. I'd rather people who do regularly use the feature weigh in on how they feel about its new behavior.
- CoastalCoder 3y ago
  For an established tool like Emacs, it must be hard to decide when it's okay to break the interface. Especially for a text editor, where longtime users' flow benefits from muscle memory.
  - deleted 3y ago
    [deleted]
- ginko 3y ago
  As a long-time emacs user who's never used registers I still think this is very poor form from the maintainers. Emacs should be about customization and changing such a basic feature without a way to return to the original behavior is pretty bad.
- tmtvl 3y ago
  It'll take me a day or two to get used to it and then it'll be fine for me. But I only really use registers to quickly jump around in buffers. If no configuration for switching to the old behaviour makes it in before Emacs 30 is released I'd be surprised if it were to take more than a week before someone makes a package that adds the old behaviour back in.
- deleted 3y ago
  [deleted]
dig1 3y ago
It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any other key because "it makes things nicer" is clearly a bug. I'm also not fond of Emacs's many subtle UX changes in the last couple of years. Enabling eldoc by default, changing "blink-matching-paren" default value... For each new Emacs release, I have to revisit my init.el and revert to the old behavior (thank you, elisp!), because suddenly things start to pop out or jump around. I get it; this is maybe to please the newer/younger crowd who are usually "in transit" - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with "a big bag of odor." Thanks to elisp, you can bend Emacs any way you want, but don't change default behavior just because "it looks nice to me".
- deleted 3y ago
  [deleted]
- norir 3y ago
  I actually think changing the default here may have been sensible. The problem is removing the old functionality entirely. This looks like a change to benefit new users (which is good) that had the hopefully unintended consequence of burning existing power users (which is very bad). The sensible compromise is to add a config flag that restores the old behavior while keeping the new default. From the outside, it's hard to see any reason other than pride for not doing that.
- samus 3y ago
  Pleasing the newer/younger crowd is important! The default experience of Emacs should make it possible for new users to get up to speed as quickly as possible. Else, Emacs will slowly fade to irrelevance until it is a museum piece. There are of course different views about how to approach this. Of course, for any change there should be switches or other possibilities to restore the old user experience. Power users (especially of Emacs) can be expected to be able to maintain their init.el file. Even the case of Spacebar Heating[0] could be handled that way. The legacy of a genuine technical bug should not impact the rest of the community forever. Some might point out that there are Emacs distributions out there that offer a modern experience. But these are hardly known to newcomers. Distribution shopping is a useless distraction before starting to use an editor which already has a higher-than-average learning curve. [0]: https://xkcd.com/1172/ https://xkcd.com/1172/
wallfacer120 3y ago
[dead]
TheRoque 3y ago
[flagged]
- samus 3y ago
  Because of this change, the author of TA will likely have to perform 6000 keystrokes more per day since he is a poweruser of that feature. And this is just one user. Seems entirely justified.
GavinAnderegg 3y ago
Reviewing the mailing list threads on this, it looks like there will be an option to revert this behaviour: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t It seems like this option was mentioned before the original post was published, but perhaps the author didn't see this? I assume this would fix the issue, but I may be missing something. -- EDIT: it looks like this will still require a RETURN keypress, based on the reply from ginko below.
- ginko 3y ago
  Seems like that still needs an extra RET to confirm register overwrites: https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/ https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
  - GavinAnderegg 3y ago
    Aha! Ok, that makes sense. I had figured the original poster would have seen this fly by, so I was confused as to why it was still an issue. Thanks!
    - nanny 3y ago
      Thierry also already offered to add another option to fully revert to the old behavior: https://yhetil.org/emacs/874jgq0zdh.fsf@posteo.net/ https://yhetil.org/emacs/874jgq0zdh.fsf@posteo.net/ Please also take note that this (completely reasonable email) is some of the so-called "bad behavior" and "arrogance" that the author of the article is purportedly describing.
- addicted 3y ago
  From that thread it does appear that register-use-previews seems to be the toggle for this behavior (although it mentions a bug where even if it’s set to never a certain workflow is prompting a confirmation). That would resolve any concerns I’d imagine if it’s truly an option?
BaculumMeumEst 3y ago
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 accomplishes is demonizing people who donate their time to the project. Already this thread has people saying stuff like “I don’t like this person.”
- layer8 3y ago
  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”.
  - BaculumMeumEst 3y ago
    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%3Fid%3D38591584%2338592984 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/kcsseyk/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/emacs/comments/18f5oi9/comment/kcss...
- cardanome 3y ago
  The actual reasonable approach would be to implement it as a strictly opt-in feature for the next release and then when many people have tested it, gather some some usage data and then decide on whether to make it the new default behavior or not. Just breaking established user behavior and muscle memory just because you think something might be better without having gathered any actual evidence is insane.
deng 3y ago
Maybe let's keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs' features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There's still discussion if overwriting registers should prompt for confirmation (which it didn't use to do). Let's wait how that one turns out. I fail to see why one would need to write a long blog post and maintain a fork because of something like this... maybe just wait it out a bit and let people voice their opinions, it takes a bit of time...
- philipwhiuk 3y ago
  > fail to see why one would need to write a long blog post and maintain a fork because of something like this... Probably because, and it certainly appears the case, that the process is being ruled by fiat not by good technical/policy decisions (and the approach of broadcast is intended to replace the fiat by overwhelming numbers)
  - deng 3y ago
    And again with the drama... The maintainer already said: he thought it was a clear improvement, so it landed on master. Now that it has landed and people use it, people react to it, and it turns out the old behavior was well beloved and it's already decided it will stay through an option. Now further details are discussed. This has happened many times before. Just give it a bit of time, voice your opinion, and hopefully a consensus will be achieved (and if not, yes, the maintainer has the last word, that's how it supposed to be). This is the master branch. It often takes months to flesh out these kind of things. You might say this should be done on a feature branch, but these get used much less and hence you'll get much less feedback.
- deleted 3y ago
  [deleted]
- Asooka 3y ago
  No program feature should ever be designed to be "friendly to newbies". Easy to use (in general) - yes; easy to learn - yes; hard to do accidentally - yes; low friction - yes; discoverable - yes. However, designing for the person who has never learned to use the feature inevitably leads to your program having a very low skill ceiling and being a disservice to power users. Also, how do you know the new design is "friendly to newbies"? You're not a newbie and neither are any of the other Emacs developers. Without lots of user studies, you have no idea what is "friendly to newbies". A more proper way to do this change would be to go "Hey, I've been running into an issue with using registers for a while and solved it for myself with this change. Let's add it as an option and vote on what the default should be." This is a much better approach, because 1. It is designed based on real user feedback. Even if it's just one user, people aren't unique, so there must be many like that person. "I like it this way" is a much stronger argument than "my imaginary newbie likes it this way". 2. It invites the rest of the community to decide on the default program behaviour. Software must serve its current users first and foremost. Thus, what the majority says should be the default is what the default should be. This is where Volpiatto and Zaretskii went wrong. A change was made and pushed to solve an imaginary problem for imaginary users without involving the people actually affected. They broke their users' trust.
lycopodiopsida 3y ago
The "maintainer" is Thierry Volpiatto, mostly known as author of helm, a completion framework.
tarsius 3y ago
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 have concluded already. Here's a recent message by Eli (and the message he is responding to). > I'm hoping the old behavior stays the default and the new behaviour > is what users can opt in with a variable. > > If that is what normally happens for much less disruptive changes, > why isn't it happening for this deep impacting one? Because the original discussion of these changes, between two people who were interested and involved, indicated that the new behavior makes much more sense than the old one. Now, that others chimed in with the opposite views, we are still discussing what should be the behavior, and once that is concluded, we can talk about the defaults. So I think this has been blown way out of proportion. IMO there are some serious issues in how Emacs is developed. I don't have a solution but I think that us users/package-maintainers thinking to ourselves "gee there sure are a lot of stubborn people on emacs-devel, what's wrong with them?" and then the second a change is made that we strongly disagree with, we start behaving like the world is ending, that might be a problem. This is how maintainers get defensive (you might have noticed that in the projects that you maintain).
- NeutralForest 3y ago
  I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".
- bachmeier 3y ago
  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.
  - rrix2 3y ago
    This is a pre-release commit not in any released version.
mtraven 3y ago
Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.
- cratermoon 3y ago
  You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.
  - morelisp 3y ago
    As far as I can tell this is simply not true. I don't think the change is a good idea but the hard fork also looks like a pure political play, not a technical one. Also, as soon as someone talks about "settings" there is usually a profound misunderstanding of how Emacs works at play.
  - 3836293648 3y ago
    No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.
    - kazinator 3y ago
      How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward. If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version. You're doing everything fork-like except calling it a fork.
      - gnulinux 3y ago
mediumsmart 3y ago
It’s a slippery slope ”it looks like you are trying to create a buffer that is not attached to a file. If that is actually what you intended please confirm with RET so that the buffer can be created but keep in mind that. . .”
philipwhiuk 3y ago
It seems like Emacs has a fairly toxic development process. Arguing that because something has been committed to the development branch it can't be reverted, is a terrible policy.
shadowgovt 3y ago
At the end of the day though, it's emacs. In lisp alone, you can get the old behavior back if you want it. I think usability decisions like this are one of the harder things to decide by committee in an open source project because they are, at the end of the day, questions of taste. And people can have conflicting and equally valid tastes. Here, a swap is being made between editing speed and accuracy, with the one perhaps having the better claim for purely historical reasons (but if you let historical reasons dictate design, you end up with faster horses not cars). Me personally, I'm a committed emacs user and I don't have skin in this game. If I don't like the new UI, I'll just add the necessary code to swap it out for the old UI.
- travisjungroth 3y ago
  This is equivocating. It’s not better for purely historical reasons, it’s just a bad trade of speed for accuracy. If you really want to be sure, is one return click enough? Maybe it should be two. Maybe a mouse click. You could throw in a five second cool down to be really sure. Obviously some of these ideas are worse than the status quo.
  - shadowgovt 3y ago
    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?"
    - travisjungroth 3y ago
      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.
      - shadowgovt 3y ago
        Well the good news is it should be straightforward to customize the old behavior back for people who don't like the trade-off.
smarx007 3y ago
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 with people. Agreeing with people while doing the complete opposite, is quite unacceptable, in my opinion. [1]: https://yhetil.org/emacs/837clv6sga.fsf@gnu.org/ https://yhetil.org/emacs/837clv6sga.fsf@gnu.org/ [2]: https://yhetil.org/emacs/87r0k2pgq6.fsf@posteo.net/ https://yhetil.org/emacs/87r0k2pgq6.fsf@posteo.net/
- deleted 3y ago
  [deleted]
- rightbyte 3y ago
  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.
deleted 3y ago
[deleted]
Kwpolska 3y ago
Is it just me, or is Emacs much more drama-prone, compared to Vim, VSCode, or any other text editor?
deleted 3y ago
[deleted]
akarve 3y ago
I was sure to read “the forces of vim have invaded our headquarters and now hold our CEO hostage.”
accelbred 3y ago
This is a bad take by the author; users wanting stability should be on the release branch, or pin commits on master. It should be expected that the development branch is used to develop in-progress features. Sometimes these take a while to hammer out. If you follow master, you will have frequent breaking changes and should be comfortable reverting to a previous commit when theres something breaking your workflow. Better yet, stay on a release.
pdyc 3y ago
it indeed looks like a bad idea. New behavior should be optional, old behavior should be default so that it does not affects existing workflow of users. I am heavy emacs user but i use stable release, i hope this change does not makes into the stable release.
JoeyBananas 3y ago
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.
velox_neb 3y ago
Looks like the Emacs developer community needs a Linus to talk some sense into these Mauros Referring of course to https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75

Bad NEWS, Emacs

357 points by amiralul 3y ago

coldtea 3y ago

[flagged]

throwaway128376 3y ago
[flagged]
addicted 3y ago
Problems with a large open source project are never about a single individual. Individuals will make mistakes and have wrong opinions. The problem here appears to lie with the larger eMacs development community.
deleted 3y ago
[deleted]

ur-whale 3y ago

OpenSource working as intended, no?

mrlonglong 3y ago
Yup. Great isn't it when the system works as intended.
tvink 3y ago
Sure, in the sense that they can differ and co-exist? Of course it's much better in OSS when differences can be resolved so that more people may work together on fewer forks, so discussion should come before forks most of the time. The author seems to be doing exactly the right thing - tried to contribute to the shared work, voice their concerns and thought process, and ultimately fork in protest.
DonHopkins 3y ago
Absolutely not! Free Software working as intended. Are you trying to trigger RMS by calling Emacs "Open Source"?
addicted 3y ago
Just because a system works doesn’t mean all outcomes out of the system when it’s working are equally good. Even the best working system will still require people to make good decisions to have the best outcomes.

MiddleEndian 3y ago

[flagged]

NikkiA 3y ago

Assuming any particular commit in git represents the eventual state of a release seems foolhardy.

marcinzm 3y ago
That's not the author's point. They did try to improve the behavior in a future commit and were shot down. Hard it seems. So were any requests from others to change this before release.
- juped 3y ago
  [flagged]
  - deleted 3y ago
    [deleted]
- chongli 3y ago
  Not only that, but the author of the original offending change asked the author of this blog to write a patch to make the change optional within the UI and then rejected the patch that was written. That seems like bad faith to me.
  - yaantc 3y ago
    Read the mailing list thread: the patch did much more than making the change optional, it did revert other related changes. That's why it was rejected. Other discussed changes were taken in, and it's not settled yet it seems: the discussion is on-going. I find the reporting here very one sided and uselessly dramatic. I read the thread and don't see arrogance, just (sometimes strong) differences of opinion. Calling "arrogant" anyone who don't agree and fold to your view, and create drama and draw the crowd against one specific person (the initial change author, OK, but it was done with maintainers in the loop) where the crowd won't check the details is not OK in my book.
    - 3y ago

jason_stelzer 3y ago

I have been using emacs since probably 94. This change, without a toggle from userspace to disable it is a kick in the pants. I will follow your fork until (if) they come around.

jhoechtl 3y ago

I someone is to fork Emacs its because of getting proper UI integration or multithreading. This is just a neglectable, whimsical step. Sorry. What Emacs needs is the nvim/vim Schisma.

PaulHoule 3y ago
There was Xemacs back in the day… and I guess it is still around.
- medstrom 3y ago
  It's still around in the same sense that twm is still around.
ajross 3y ago
> What Emacs needs is the nvim/vim Schisma. It's already had like six, over the decades.
PurpleRamen 3y ago
There are enough unsuccessful forks of GNU Emacs. None of them get enough attention and support for whatever reason, but I guess mainly because there have no real reason to exist. Emacs devs are working diligently and improving it regularly, and there is no good and simple solution for the problems it has. There won't be any nvim/vim-like Schisma happen, unless some super-dev appears who can outsmart the whole community and it's devs. Maybe, in a decade when AI become good enough and someone feeds Emacs to electron or something like that.

devnull3 3y ago

I am a Vim guy. Can someone explain what exactly is broken?

Narishma 3y ago
It's explained in the article.
- isodev 3y ago
  I’m not an Emacs user and also failed to understand what went wrong. So they changed a default shortcut or something?
  - doix 3y ago
    I also don't really use emacs. But by the sounds of it, when you want to use a command that involves a register, you get a mini-popup where you input the register you want. The downside is that you must push enter after you enter the register you want.
  - lvncelot 3y ago
    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.
    - Kalq 3y ago
      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.
- devnull3 3y ago
  I could not understand and hence I asked the question. The thing I understood was that this broke some peoples flow.

ajross 3y ago

It's a good rant, but it probably doesn't help its case that it doesn't stop to explain what the feature it's talking about actually is. Emacs registers are a really, really old abstraction. Registers are like separate clipboards, you can put stuff there and pull it out. And there are 62 of them (each associated with a core ASCII symbol: [a-zA-Z0-9]), giving you a lot of flexibilty and a very quick keyboard interface for acting on/with them. And you can even do fun stuff like execute a keyboard macro out of a register. Some people use them heavily. I don't. Anyway the author is peeved that they changed the default bindings such that there's a modal UI in the way of what used to be a fully-keyboard/home-row operation. It sounds like a reasonable complaint; I'd be annoyed too if they changed something that lived in my muscle memory like this kind of feature does.

tinus_hn 3y ago
‘Default bindings’ sounds like it’s configurable to be different. Is it?
- jsw97 3y ago
  It is not. That approach was tried and rejected, hence the problem.
  - morelisp 3y ago
    In the interest of fairness, it should be noted a very specific solution was tried and rejected (providing configuration variables to adjust the behavior of `register-read-with-preview`). I personally don't see anything preventing users from configuring alternate commands which call directly `set-register` and mapping those as they please, so in that sense it is still configurable. And in the extreme case you could even use advices, etc. It is very difficult to make something non-configurable in Emacs and I don't see the register system being so ingrained as to be one of those things. Whether it's a good idea... well, I don't use registers but the whole thing seems like a bad idea to me. I don't think I know anyone who uses registers and would like the new behavior. (But I also understand the desire to modernize `register-read-with-preview` a bit. A better solution seems like it would be providing multiple implementations so users can do the register equivalent of `(fset #'yes-or-no-p #'y-or-n-p)` like every old Emacs user does today.)

pilgrim0 3y ago

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 change is the hallmark of security, it should be mandatory for every user”. Come on…

janice1999 3y ago
I disagree. As a developer I think breaking literally decades old workflows for users without notice or any level of concern is a bad thing. For a program with users so reliant on muscle memory, I think the impact is far worse.
- smitty1e 3y ago
  The friction seemed less about the change as such as in the unilateral delivery. Even good change (whether or not this is) needs a gentle transition.
  - jonathanstrange 3y ago
    If I understood this correctly, the new behavior cannot be customized back to the old behavior. If that's true, then that's obviously very bad. Generally, as an Emacs user, I don't just want an opt-in or a gentle transition, I need to be able to customize everything to my needs.
    - smitty1e 3y ago
      This is Emacs, so one presumes that it's a SMOeL (Simple Matter Of eLisp) problem. However, it seems tasteless to impose the burden.
potatopatch 3y ago
Inventing new things who cares, but for existing key sequences its a problem even if the new sequence would have been better. Imagine when some of these soft cars start adding power steering in an overnight update.

entropie 3y ago

> Since then, another bug report came in from a Emacs master branch user that suffered from one of the consequences of this change (a specific regression that I spelled out days before, but was ignored, for some reason), and several users reached out to the Emacs development in request to restore the previous behavior in an ongoing thread titled “Please, Restore Previous Behavior for jump-to-register”. Astonishingly, Eli and Thierry won’t seem to budge, and Emacs 30 will thus likely suck. Seriously, this is kind of funny. I use emacs for like two decades now and I knew about jump-to-register but never actively used it. But yes - emacs 30 will be bad because of this change. Barely useable anymore. This guys in their mailinglist have... very specific problems. You heard it first here. Emacs 30 will suck. Also; https://xkcd.com/1172/ https://xkcd.com/1172/ hits the spot and is - what a coincidence - about emacs and workflows.

kyrra 3y ago
While I understand your point, emacs is changing very specific behavior, that was intended, to do something new now. So I would say you're xkcd comment is slightly off.
- entropie 3y ago
  > emacs is changing very specific behavior, that was intended, to do something new now No? It changes how an existing command behaves. > This commit crippled all user interaction with Emacs registers, turning commands such as C-x r s, once smooth and frictionless, into a cumbersome and painful mess. Concretely, instead of just typing the key for the register you want to operate on, you now get a fully blown minibuffer for inserting a single key.
  - broscillator 3y ago
    with all due respect c-x r s sounds far from smooth and frictionless to me
    - monsieurbanana 3y ago

juped 3y ago

This is really polemically overstating the case, but at least it links to the mailing list threads where you can see what's actually going on. Not that anyone will click them.

mixedmath 3y ago

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 easily configuring this away). Further, this happened without much discussion. Let's state a vim analogy. If I want to copy the current line into my `d` register, I can type `"dyy`. This proposal would do something like, after typing `"dyy`, open up a scratch buffer that tells the user the text and the buffer, requiring a keystroke to close. This is terrible for people who understand registers (the typical vim user). But I acknowledge that sometimes I don't copy the intended text into registers and have to try again. I also know many vim people who only yank from visual mode, which has a similar show-explicitly-what-is-being-copied behavior. The rest of this article is a description of how the OP tried to raise discussion, but the commit-author, Thierry, shot it down. Implicitly the rest of the emacs dev community is at fault too.

Zelphyr 3y ago
I just learned a new feature of Vim. Thank you!
- motoboi 3y ago
  vimtutor is absolutely worth the time
  - xhevahir 3y ago
    I don't think that feature is covered in vimtutor. As far as I can tell vimtutor mentions registers only once in passing and buffers not at all.
CoastalCoder 3y ago
As a perpetually novice vim user, I actually would have expected "dyy" to mean Delete the current line. But that probably just proves my novice status.

krmboya 3y ago

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

atticora 3y ago
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 has escalated to "fork you".
- stjohnswarts 3y ago
  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
bradleyjg 3y ago
Not just emacs. I don’t care about emacs at all. What makes this story important is pointing out the arrogance of devs that love to “improve” things without any regard for people’s settled expectations. That applies as much to google maps or iOS as it does to emacs.
runevault 3y ago
At a minimum switching anything that breaks muscle memory should be a toggle that defaults to "keep my config how it used to be"
layer8 3y ago
More generally, any frequently used software should be made “muscle-memorizable”, and then should not break it in later versions without good reasons. Muscle memory has the benefit of enabling “blind” and semi-asynchronous operation of the software, without constant visual confirmation for each micro-interaction. There’s unfortunately a trend in desktop software to make operation by keyboard ever more cumbersome or outright impossible.

blantonl 3y ago

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?

morelisp 3y ago
I imagine it's that reading user input through something other than the minibuffer is annoying, because if you have customized your input/editing keys, read-key generally won't reflect that.
lvncelot 3y ago
This is what I've been wondering here, as well. So far, the downsides (Change to an almost subconscious muscle-memory-task, added friction) of this are pretty apparent - what even are the upsides of this?
- rjzzleep 3y ago
  Attracting new users for with the old behaviour is too complex maybe?
  - dromtrund 3y ago
    Isn't named registers an advanced enough feature that it shouldn't be optimized for new users?
  - samus 3y ago
    The new behavior doesn't make me want to invest effort in learning registers. A notification in the status bar which register just got filled would be all I want.
  - mahkoh 3y ago
    I believe Mozilla has been successful with a similar strategy.
- vcg3rd 3y ago
  I use Emacs, mostly for Org Mode, but not registers. I also understand perfectly the problem, and I also can't understand the upside. The only clue I see is in the polite objection the author quotes who writes "I agree it's safer..." But I don't understand safer in what way or why 1 person gets to decide safer=better=forced.

mynegation 3y ago

It’s been 20 years since I left Emacs, but I understand that this change is pretty disruptive. What I do not understand is why Emacs that prides itself in being the “kitchen sink” did not add an option to revert to the old behaviour.

tsimionescu 3y ago
They are adding it, most likely. The author of this article is just mad that they didn't accept their patch (which added a flag but also did away with all the other improvements).

binary132 3y ago

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.

CoastalCoder 3y ago
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?
- domq 3y ago
  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.
  - kazinator 3y ago
    Your alternate implementation would have to monkey patch the shipped code. That is a fork in disguise. Not to repeat myself: https://news.ycombinator.com/item?id=38604600 https://news.ycombinator.com/item?id=38604600 The easiest way to produce a monkey patch for Emacs which reverts some behavior would be to maintain your own private fork of the repo, where you do a proper job of rebasing, resolving conflicts and validating. Then from that you take the necessary files (all the files that are different from upstream) and produce the hot-load that can be distributed to people. But, totally not a fork, man!
samus 3y ago
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.

wavemode 3y ago

This thread is mostly "I don't use this feature of Emacs (or Emacs at all) therefore this isn't a real problem, so stop complaining." Poor to see. I'd rather people who do regularly use the feature weigh in on how they feel about its new behavior.

CoastalCoder 3y ago
For an established tool like Emacs, it must be hard to decide when it's okay to break the interface. Especially for a text editor, where longtime users' flow benefits from muscle memory.
- deleted 3y ago
  [deleted]
ginko 3y ago
As a long-time emacs user who's never used registers I still think this is very poor form from the maintainers. Emacs should be about customization and changing such a basic feature without a way to return to the original behavior is pretty bad.
tmtvl 3y ago
It'll take me a day or two to get used to it and then it'll be fine for me. But I only really use registers to quickly jump around in buffers. If no configuration for switching to the old behaviour makes it in before Emacs 30 is released I'd be surprised if it were to take more than a week before someone makes a package that adds the old behaviour back in.
deleted 3y ago
[deleted]

dig1 3y ago

It may be an unpopular approach, but I'm a fan of Linus's "you must never break user-space/UX." Some changes might be trivial for you or even an "improvement" (which is mostly a personal opinion, especially regarding UX, unless you prove it with many research papers or have many complaints). Still, if I hit some key combos 100 times a day in the last 20 years, that became second nature for me. Adding Enter or any other key because "it makes things nicer" is clearly a bug. I'm also not fond of Emacs's many subtle UX changes in the last couple of years. Enabling eldoc by default, changing "blink-matching-paren" default value... For each new Emacs release, I have to revisit my init.el and revert to the old behavior (thank you, elisp!), because suddenly things start to pop out or jump around. I get it; this is maybe to please the newer/younger crowd who are usually "in transit" - yesterday were on Vim, today, are on Emacs, and tomorrow, who knows, leaving us regular users with "a big bag of odor." Thanks to elisp, you can bend Emacs any way you want, but don't change default behavior just because "it looks nice to me".

deleted 3y ago
[deleted]
norir 3y ago
I actually think changing the default here may have been sensible. The problem is removing the old functionality entirely. This looks like a change to benefit new users (which is good) that had the hopefully unintended consequence of burning existing power users (which is very bad). The sensible compromise is to add a config flag that restores the old behavior while keeping the new default. From the outside, it's hard to see any reason other than pride for not doing that.
samus 3y ago
Pleasing the newer/younger crowd is important! The default experience of Emacs should make it possible for new users to get up to speed as quickly as possible. Else, Emacs will slowly fade to irrelevance until it is a museum piece. There are of course different views about how to approach this. Of course, for any change there should be switches or other possibilities to restore the old user experience. Power users (especially of Emacs) can be expected to be able to maintain their init.el file. Even the case of Spacebar Heating[0] could be handled that way. The legacy of a genuine technical bug should not impact the rest of the community forever. Some might point out that there are Emacs distributions out there that offer a modern experience. But these are hardly known to newcomers. Distribution shopping is a useless distraction before starting to use an editor which already has a higher-than-average learning curve. [0]: https://xkcd.com/1172/ https://xkcd.com/1172/

wallfacer120 3y ago

[dead]

TheRoque 3y ago

[flagged]

samus 3y ago
Because of this change, the author of TA will likely have to perform 6000 keystrokes more per day since he is a poweruser of that feature. And this is just one user. Seems entirely justified.

GavinAnderegg 3y ago

Reviewing the mailing list threads on this, it looks like there will be an option to revert this behaviour: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t It seems like this option was mentioned before the original post was published, but perhaps the author didn't see this? I assume this would fix the issue, but I may be missing something. -- EDIT: it looks like this will still require a RETURN keypress, based on the reply from ginko below.

ginko 3y ago
Seems like that still needs an extra RET to confirm register overwrites: https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/ https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
- GavinAnderegg 3y ago
  Aha! Ok, that makes sense. I had figured the original poster would have seen this fly by, so I was confused as to why it was still an issue. Thanks!
  - nanny 3y ago
    Thierry also already offered to add another option to fully revert to the old behavior: https://yhetil.org/emacs/874jgq0zdh.fsf@posteo.net/ https://yhetil.org/emacs/874jgq0zdh.fsf@posteo.net/ Please also take note that this (completely reasonable email) is some of the so-called "bad behavior" and "arrogance" that the author of the article is purportedly describing.
addicted 3y ago
From that thread it does appear that register-use-previews seems to be the toggle for this behavior (although it mentions a bug where even if it’s set to never a certain workflow is prompting a confirmation). That would resolve any concerns I’d imagine if it’s truly an option?

BaculumMeumEst 3y ago

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 accomplishes is demonizing people who donate their time to the project. Already this thread has people saying stuff like “I don’t like this person.”

layer8 3y ago
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”.
- BaculumMeumEst 3y ago
  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%3Fid%3D38591584%2338592984 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/kcsseyk/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/emacs/comments/18f5oi9/comment/kcss...
cardanome 3y ago
The actual reasonable approach would be to implement it as a strictly opt-in feature for the next release and then when many people have tested it, gather some some usage data and then decide on whether to make it the new default behavior or not. Just breaking established user behavior and muscle memory just because you think something might be better without having gathered any actual evidence is insane.

deng 3y ago

Maybe let's keep the drama down a bit? There was a change committed which made using registers more friendly to use for newbies. IMHO, working on making Emacs' features more accessible is a good thing. And yes, this of course annoys old-school Emacs users (including me). AFAICS the discussion is still very much in progress. There will be an option added to be able to revert to the old behavior. There's still discussion if overwriting registers should prompt for confirmation (which it didn't use to do). Let's wait how that one turns out. I fail to see why one would need to write a long blog post and maintain a fork because of something like this... maybe just wait it out a bit and let people voice their opinions, it takes a bit of time...

philipwhiuk 3y ago
> fail to see why one would need to write a long blog post and maintain a fork because of something like this... Probably because, and it certainly appears the case, that the process is being ruled by fiat not by good technical/policy decisions (and the approach of broadcast is intended to replace the fiat by overwhelming numbers)
- deng 3y ago
  And again with the drama... The maintainer already said: he thought it was a clear improvement, so it landed on master. Now that it has landed and people use it, people react to it, and it turns out the old behavior was well beloved and it's already decided it will stay through an option. Now further details are discussed. This has happened many times before. Just give it a bit of time, voice your opinion, and hopefully a consensus will be achieved (and if not, yes, the maintainer has the last word, that's how it supposed to be). This is the master branch. It often takes months to flesh out these kind of things. You might say this should be done on a feature branch, but these get used much less and hence you'll get much less feedback.
deleted 3y ago
[deleted]
Asooka 3y ago
No program feature should ever be designed to be "friendly to newbies". Easy to use (in general) - yes; easy to learn - yes; hard to do accidentally - yes; low friction - yes; discoverable - yes. However, designing for the person who has never learned to use the feature inevitably leads to your program having a very low skill ceiling and being a disservice to power users. Also, how do you know the new design is "friendly to newbies"? You're not a newbie and neither are any of the other Emacs developers. Without lots of user studies, you have no idea what is "friendly to newbies". A more proper way to do this change would be to go "Hey, I've been running into an issue with using registers for a while and solved it for myself with this change. Let's add it as an option and vote on what the default should be." This is a much better approach, because 1. It is designed based on real user feedback. Even if it's just one user, people aren't unique, so there must be many like that person. "I like it this way" is a much stronger argument than "my imaginary newbie likes it this way". 2. It invites the rest of the community to decide on the default program behaviour. Software must serve its current users first and foremost. Thus, what the majority says should be the default is what the default should be. This is where Volpiatto and Zaretskii went wrong. A change was made and pushed to solve an imaginary problem for imaginary users without involving the people actually affected. They broke their users' trust.

lycopodiopsida 3y ago

The "maintainer" is Thierry Volpiatto, mostly known as author of helm, a completion framework.

tarsius 3y ago

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 have concluded already. Here's a recent message by Eli (and the message he is responding to). > I'm hoping the old behavior stays the default and the new behaviour > is what users can opt in with a variable. > > If that is what normally happens for much less disruptive changes, > why isn't it happening for this deep impacting one? Because the original discussion of these changes, between two people who were interested and involved, indicated that the new behavior makes much more sense than the old one. Now, that others chimed in with the opposite views, we are still discussing what should be the behavior, and once that is concluded, we can talk about the defaults. So I think this has been blown way out of proportion. IMO there are some serious issues in how Emacs is developed. I don't have a solution but I think that us users/package-maintainers thinking to ourselves "gee there sure are a lot of stubborn people on emacs-devel, what's wrong with them?" and then the second a change is made that we strongly disagree with, we start behaving like the world is ending, that might be a problem. This is how maintainers get defensive (you might have noticed that in the projects that you maintain).

NeutralForest 3y ago
I'm fully with you here; let the process happen and the discussion between contributors and maintainers happen before talking about "BAD NEWS".
bachmeier 3y ago
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.
- rrix2 3y ago
  This is a pre-release commit not in any released version.

mtraven 3y ago

Seriously, WTF? The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense. Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.

cratermoon 3y ago
You must have missed the part where this change does not include the ability to revert to the old behavior via any settings.
- morelisp 3y ago
  As far as I can tell this is simply not true. I don't think the change is a good idea but the hard fork also looks like a pure political play, not a technical one. Also, as soon as someone talks about "settings" there is usually a profound misunderstanding of how Emacs works at play.
- 3836293648 3y ago
  No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.
  - kazinator 3y ago
    How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward. If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version. You're doing everything fork-like except calling it a fork.
    - gnulinux 3y ago

mediumsmart 3y ago

It’s a slippery slope ”it looks like you are trying to create a buffer that is not attached to a file. If that is actually what you intended please confirm with RET so that the buffer can be created but keep in mind that. . .”

philipwhiuk 3y ago

It seems like Emacs has a fairly toxic development process. Arguing that because something has been committed to the development branch it can't be reverted, is a terrible policy.

shadowgovt 3y ago

At the end of the day though, it's emacs. In lisp alone, you can get the old behavior back if you want it. I think usability decisions like this are one of the harder things to decide by committee in an open source project because they are, at the end of the day, questions of taste. And people can have conflicting and equally valid tastes. Here, a swap is being made between editing speed and accuracy, with the one perhaps having the better claim for purely historical reasons (but if you let historical reasons dictate design, you end up with faster horses not cars). Me personally, I'm a committed emacs user and I don't have skin in this game. If I don't like the new UI, I'll just add the necessary code to swap it out for the old UI.

travisjungroth 3y ago
This is equivocating. It’s not better for purely historical reasons, it’s just a bad trade of speed for accuracy. If you really want to be sure, is one return click enough? Maybe it should be two. Maybe a mouse click. You could throw in a five second cool down to be really sure. Obviously some of these ideas are worse than the status quo.
- shadowgovt 3y ago
  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?"
  - travisjungroth 3y ago
    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.
    - shadowgovt 3y ago
      Well the good news is it should be straightforward to customize the old behavior back for people who don't like the trade-off.

smarx007 3y ago

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 with people. Agreeing with people while doing the complete opposite, is quite unacceptable, in my opinion. [1]: https://yhetil.org/emacs/837clv6sga.fsf@gnu.org/ https://yhetil.org/emacs/837clv6sga.fsf@gnu.org/ [2]: https://yhetil.org/emacs/87r0k2pgq6.fsf@posteo.net/ https://yhetil.org/emacs/87r0k2pgq6.fsf@posteo.net/

deleted 3y ago
[deleted]
rightbyte 3y ago
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.

deleted 3y ago

[deleted]

Kwpolska 3y ago

Is it just me, or is Emacs much more drama-prone, compared to Vim, VSCode, or any other text editor?

deleted 3y ago

[deleted]

akarve 3y ago

I was sure to read “the forces of vim have invaded our headquarters and now hold our CEO hostage.”

accelbred 3y ago

This is a bad take by the author; users wanting stability should be on the release branch, or pin commits on master. It should be expected that the development branch is used to develop in-progress features. Sometimes these take a while to hammer out. If you follow master, you will have frequent breaking changes and should be comfortable reverting to a previous commit when theres something breaking your workflow. Better yet, stay on a release.

pdyc 3y ago

it indeed looks like a bad idea. New behavior should be optional, old behavior should be default so that it does not affects existing workflow of users. I am heavy emacs user but i use stable release, i hope this change does not makes into the stable release.

JoeyBananas 3y ago

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.

velox_neb 3y ago

Looks like the Emacs developer community needs a Linus to talk some sense into these Mauros Referring of course to https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75