[HN Gopher] Bad NEWS, Emacs
___________________________________________________________________
Bad NEWS, Emacs
Author : amiralul
Score : 305 points
Date : 2023-12-10 14:07 UTC (8 hours ago)
(HTM) web link (eshelyaron.com)
(TXT) w3m dump (eshelyaron.com)
| ur-whale wrote:
| OpenSource working as intended, no?
| mrlonglong wrote:
| Yup. Great isn't it when the system works as intended.
| tvink wrote:
| 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 wrote:
| Absolutely not! Free Software working as intended. Are you
| trying to trigger RMS by calling Emacs "Open Source"?
| addicted wrote:
| 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.
| NikkiA wrote:
| Assuming any particular commit in git represents the eventual
| state of a release seems foolhardy.
| marcinzm wrote:
| 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.
| chongli wrote:
| 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 wrote:
| 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.
| chongli wrote:
| Then there is bad faith, it's just bad faith on the part
| of the linked blogger.
| jason_stelzer wrote:
| 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 wrote:
| 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 wrote:
| There was Xemacs back in the day... and I guess it is still
| around.
| medstrom wrote:
| It's still around in the same sense that twm is still around.
| ajross wrote:
| > What Emacs needs is the nvim/vim Schisma.
|
| It's already had like six, over the decades.
| PurpleRamen wrote:
| 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 wrote:
| I am a Vim guy. Can someone explain what exactly is broken?
| Narishma wrote:
| It's explained in the article.
| isodev wrote:
| I'm not an Emacs user and also failed to understand what went
| wrong. So they changed a default shortcut or something?
| doix wrote:
| 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 wrote:
| 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.
| devnull3 wrote:
| I could not understand and hence I asked the question. The
| thing I understood was that this broke some peoples flow.
| morelisp wrote:
| They did the Emacs equivalent of adding a confirmation dialog
| to an action which some people do very frequently (like tens of
| times per minute). I think it also fundamentally breaks some
| rarer use cases I would have trouble explaining to non-Emacs
| users, but do seem somewhat valuable.
|
| It's not clear to me from the messages I read why this can't be
| worked around without a hard fork, although I do agree it's an
| obvious bad decision to begin with, and obvious to me even as
| someone who barely uses this feature.
| rcthompson wrote:
| Looking at the commit diff, I don't see anything that
| necessitates a hard fork. The changes are all in elisp, not
| compiled C code. It looks like just evaluating the old
| version of register.el (perhaps with a few compatibility
| changes) in an Emacs session would revert everything to the
| old behavior.
| hattar wrote:
| https://news.ycombinator.com/item?id=38591788
|
| This person seems to explain it well
| djha-skin wrote:
| In Vim speak:
|
| Imagine you create a bunch of recorded keyboard macros that
| store stuff in different registers. Now this change comes and
| instead of typing `"ay` you have to press `"a<Enter>y`. Indeed
| any time you store to a register (`"a`) you have to add an
| enter key. This breaks all of your keyboard macros and all of
| your muscle memory made over the past twenty years or more.
|
| This is why people are upset.
| Exuma wrote:
| Ive used vim for 10+ years, and I have known about yanking to
| different registers, but usually I only use the main register
| 99.9999% of the time. can you explain your use cases for
| using multiple registers? I should start doing this perhaps,
| but I can't think of many times I want to copy more than one
| thing at once, maybe once a month? But I also could be not
| thinking of the right examples.
| pmontra wrote:
| First thing I thought about: yank a line to a, yank another
| line to b; move somewhere into the file; paste from a, move
| two lines down, paste from b; repeat N times or create a
| macro for it. Basically it will be macro with two inputs,
| the contents of the a and b registers.
| ramses0 wrote:
| "ayy - copy function signature "byy - copy
| return signature "ap "bp - paste either...
| :reg - show all registers "3p - paste 3rd
| "historical" register "_dd - delete into the
| /dev/null buffer (so you don't eat your `yy` register that
| you'd already yanked)
|
| It's admittedly a bit of an advanced/esoteric feature, but
| being able to paste "this part" or "that part" being
| somewhat context dependent is useful.
|
| Also useful in the context of macros... A, B, C being
| differing bits you might be "lifting", and then placing
| somewhere. i<c-r>" / i<c-r>a - recall
| (while in insert mode) the default, or the named register.
|
| Imagine that your converting `function do_something() { ...
| }` to: `arr["do_something"] = function() { ... }`
|
| You could delete the function name into "A", the function
| body into "B", then go back to your marked spot, and pull
| out the "A" into the hash key, and put "B" as the key
| value.
|
| It's reeeally awkward and complicated until you use it and
| it becomes a natural part of your way of thinking. Then it
| becomes "simply" two extra characters to type when working
| with _any_ copy/paste task and then you have a super-power
| of 26 choices of holding things off to the side.
|
| `<c-r>$REG` is honestly one of the best "beginner" uses of
| registers. It lets you "inline type" what you've just
| lifted/cut. eg: vwy - yank visible word
| into default register V"ay - yank whole line into
| register "a" I<c-r>"=<c-r>"+1 => `word = word + 1`
| (without having to exit insert mode!) "ap - paste
| the line from register "a"
|
| ...it's a small thing, but an important aspect of "vim as a
| live text-based programming language", having a few "hot"
| named variables / text strings, and being able to see them
| and manipulate them. It's literally just the double-quote
| key and ":reg" that gives you access to it.
| Exuma wrote:
| Ah this is incredible, thank you. I didnt realize that
| about <c-r>... wow, that is crazy cool.
|
| Next question, do you usually add stuff to buffers in
| alphabetical order... a,b,c or do you pick something
| easier within reach like a,s,d (or something else
| entirely)
| Tyr42 wrote:
| Usually I yank into like p or something when I want to not
| just paste later, but delete something and then paste. I
| hate it when I delete something to make room for what I
| paste and it gets rid of it. Then I fumble with the
| numbered registers and mess it up.
|
| Or when I select something and then paste and I actually
| wanted to keep my paste buffer and not replace it
| dw_arthur wrote:
| I do code in a gate around a few registers for macros and
| marks. I hate recording a macro and then accidentally
| overwriting it.
| raverbashing wrote:
| The Emacs development process
|
| No, I'm not kidding
|
| There is no focus, there's no objective, it seems the louder
| ideas win but there's no final idea of what Emacs should look
| like or what/how it should do or not
|
| That's why such breaking changes get in without questioning
| (and even why they were using such functionality as registers
| in the first place)
| lemper wrote:
| yea seems right. tfa says that thierry didn't accept input at
| all from other maintainers. that's not good in my eyes.
| ajross wrote:
| 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 wrote:
| 'Default bindings' sounds like it's configurable to be
| different. Is it?
| jsw97 wrote:
| It is not. That approach was tried and rejected, hence the
| problem.
| morelisp wrote:
| 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.)
| morelisp wrote:
| There are more than 62. One of the complaints is that the
| minibuffer breaks access to e.g. the C-a register. One person I
| know uses letters for positions and C-letter for text so while
| this may be a very edge case for some I imagine they will be
| very upset...
| huggingmouth wrote:
| I stopped using emacs a long while ago but I rely on x11
| selection buffers (middle click paste) heavily so i can relate.
| I'd absolutly be miffed to find a confirmation model dialog
| shoved between each select and paste operation AND a lack of a
| setting to revert to the old behavior.
|
| I say implement the old behavior as an option. It's literally a
| few extra lines of code.
| jason_stelzer wrote:
| It's basically global uac-mode for all buffers without the
| ability to turn it off. If it weren't true it would be
| laughable.
| dannyfreeman wrote:
| Sounds like Eli is not married to this as the default behavior
| (I'm not a fan of it either).
|
| From https://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/
|
| Eli says:
|
| > 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.
| pilgrim0 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dack wrote:
| Breaking backward compatibility should be reserved for extreme
| cases, and this doesn't sound like one. It's possible the way
| the author handled it was poor and caused part of the dispute,
| but I think the right thing would be to make such behavior opt-
| in or at least very easy to disable.
| ta988 wrote:
| This is something that should just have been made as a new
| function not replacing an existing one. That way users have a
| choice between speed when they know what register to use and
| help when they don't.
| sgbeal wrote:
| > "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 change.
| binary132 wrote:
| Social problems caused by intense and antisocial personalities?
| In MY free software project?
|
| It's more common than you think.
| praptak wrote:
| > Oh my gosh, I'll have to press 1 extra key now
|
| This key is in a context which is about as bad as Ctrl-C ("Do
| you really want to copy this text into clipboard? [Y/n]")
| doubloon wrote:
| not minor at all. you do something 100 times a day, adding
| multiple seconds to that time is not only wasting time, it is
| increasing the 'cognitive load' on the human brain.
|
| this is why you find in a lot of Operations centers, people
| have a dozen different systems where time-wasting
| "improvements" like this have been made over 20+ years, so each
| little time-wasting "improvement" has added up over time so now
| it takes like 10 minutes to do something that should take 10
| seconds. (in other words, "why does an Airline clerk have to
| spend 5 minutes typing in order to do something for my
| ticket/account", or "how did they mess up my request so badly",
| the answer is what im talking about)
|
| what it all really boils down to is a fundamental lack of
| respect for other people. if you respected other people, you
| would not break their workflow like this and then dismiss their
| concerns as unimportant.
| entropie wrote:
| > 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/ hits the spot and is - what a
| coincidence - about emacs and workflows.
| kyrra wrote:
| 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 wrote:
| > 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 wrote:
| with all due respect c-x r s sounds far from smooth and
| frictionless to me
| monsieurbanana wrote:
| If you're so used to type C-x that you don't even
| register it, like most emacs users, then it's just
| pressing "r s" for "register save".
|
| It's not terrible, and the mnemonic is sound. If you
| don't like it, perfectly valid opinion, you're just not
| made for emacs' default behavior.
| Finnucane wrote:
| 'Frictionless' here means 'we've done it this way forever
| and don't have to think about it anymore.'
| mjw1007 wrote:
| True. The traditional binding was was just `C-x x`, but
| they've already done one round of making register
| features more inconvenient to get at.
| tom_ wrote:
| If you use this stuff a lot, it is totally going to suck. Some
| thing has changed, that may or may not have a good technical
| reason, that means that after years of the program training you
| into behaving one way (and it's not like this is some crazy
| workflow you've invented yourself, right - this is literally
| you following the documented process) you're now being punished
| for it by having it not work.
|
| You wouldn't even treat your dog like this.
| addicted wrote:
| I'm a VIM user, not an emacs user so I don't have a dog in this
| fight, but if the equivalent change was made in VIM it would
| pretty much be unusable for me. My muscle memory related to
| this feature would be completely broken.
|
| I can't think of any such change in VIM being made without a
| setting to turn it off.
| lvncelot wrote:
| I mean, we're talking about changing intended behavior here and
| not accepting any discussion regarding that. Just because you
| didn't use jump-to-register, doesn't mean no one does. Again,
| this is not people using unintended consequences of edge-case-
| behavior, this is people complaining (rightfully so) about
| regressions that stem from changing the _intended_ UI.
| juped wrote:
| 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 wrote:
| 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 wrote:
| I just learned a new feature of Vim. Thank you!
| motoboi wrote:
| vimtutor is absolutely worth the time
| xhevahir wrote:
| 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 wrote:
| 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.
| addicted wrote:
| You're missing the double quote before the 'd' which means
| you're talking about a register.
| CoastalCoder wrote:
| Ah, thanks. You're right, my brain parsed the gp's comment
| as simply "dyy".
| Schiphol wrote:
| Just for completion, `dd` deletes the current line in
| vim. I'm not sure what `dyy` should do, if anything.
| tmtvl wrote:
| Maybe it should remove the top item from the list of
| copied items? Assuming that vim has one of those (in
| Emacs parlance it's called the kill ring).
| duskwuff wrote:
| > I'm not sure what `dyy` should do, if anything.
|
| Currently, nothing. `y` isn't a defined motion.
| yayitswei wrote:
| Fortunately I use evil mode so my workflow is unaffected, for
| now.
| kreetx wrote:
| The way I read it, both methods will continue to be
| available, so I guess it's a question of defaults. (So it
| doesn't really affect anyone's workflow)
| wokwokwok wrote:
| > Implicitly the rest of the emacs dev community is at fault
| too.
|
| ?
|
| I can't tell what this comment is supposed to mean.
|
| He disagrees; other people also felt similarly about it but,
| they were ignored.
|
| They say, if you don't like it, why don't you contribute?
| ...but he _did_ and that wasn't acceptable either, so he's
| forked it.
|
| Do you feel it's out of order to walk your own path with _free
| software_ if you disagree with the maintainers? Isn't that the
| whole point of GNU?
| oefrha wrote:
| > A commit that changes how copying (...) works in emacs
|
| To people who don't use Emacs, it should be made clear that
| standard copying (kill-ring-save, M-w by default) isn't
| affected, only more advanced saving to registers is. Registers
| aren't a superset of the clipboard (kill ring).
|
| Edit: In addition, those in this thread claiming that the
| change won't be configurable must have no idea of Emacs'
| customizability, namely the "settings" are for convenience
| only, you can switch out all the code if you want to. This is
| in the elisp part of Emacs, even if it lands without change
| (doubt it, after reading the actual mailing list thread rather
| than this one-sided tantrum), someone will have a package
| within minutes changing the behavior. No, you don't need a fork
| for that, the forking here is performative at best.
| ekidd wrote:
| 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, advanced editing
| features for people who want to rely on muscle memory.
|
| Adding a confirmation keystroke here is a bit weird. It's a bit
| like taking an electric piano and adding a confirmation pedal
| to confirm unusual chords. It just adds one more step to a
| rapid, complex input operation.
|
| 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.
|
| So making a breaking change here is odd, and offering no way to
| disable it would make a lot of users upset.
|
| Emacs predates modern GUI conventions. It's never going to be
| as familiar to new users as vscodium. So I think there's a good
| argument for serving power users as well as possible. That
| isn't to say that Emacs should never tweak the default config
| or add user-friendly features like the menu bar or visible
| selections. But it does suggest leaving things like registers
| mostly alone.
| medstrom wrote:
| Great points! If you don't participate in emacs development,
| maybe it's time to consider it.
| tzs wrote:
| > 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 missed by a key and typed 't' would it be noticeable
| right away?
|
| 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. By the time I
| notice the error it would be annoying to undo all the way
| back to the mis-copy.
|
| If copying into the wrong register was common enough to need
| to be addressed, my first thought would be something like
| adding a status message pups up for a short time near the
| cursor that says something like "Copied to 't'".
| davidkunz wrote:
| > yank from visual mode, which has a similar show-explicitly-
| what-is-being-copied behavior.
|
| Even better: vim.highlight.on_yank
| tsimionescu wrote:
| 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. In particular, the
| universal Emacs cancel key, C-g, would not work here: instead,
| the text or position would be saved to a register called ^g.
| Similarly, if you accidentally hit "jump-to-register" or
| "insert-register", you couldn't cancel with C-g (or with any
| other key), you'd be forced to select a register and it's
| contents would be jumped to/ inserted (if any).
|
| Secondly, registers can hold text, a position, or nothing.
| jump-to-register only works if a register holds a position,
| while insert-register expects a text. Emacs includes a preview
| of registers which are non-empty when invoking these commands,
| but it doesn't distinguish - it will show you a register that
| includes strings as an option for jump-to-register, even though
| it knows it won't work.
|
| So, Thierry took the time to address all of these concerns, and
| to address other feedback about the code. The reviewers agreed
| that these are important changes even though they add some
| extra interaction, and that the breaking change (having to hit
| RET after selecting a normal registry, or having to use an
| extra key to save to a weird register like ^g) are worth the
| gains. After it was done, and compiled, it was added by the
| Emacs maintainers to the development branch.
|
| The author of this article came along, asked for a switch to
| revert between the new and the old behavior, and was asked for
| a patch. They provided a patch that reverted all of the changes
| I mentioned before (so, no way to cancel the register commands,
| no way to get contextual help about which registers contain
| text VS position, nothing) and instead implemented an entirely
| different feature (confirmation on overwriting a non-empty
| register based on a flag). Thierry installed the author's new
| patch and gave this simple feedback, to which the author
| basically replied "you don't need all that".
|
| Now, as more people started using the feature, the belief by
| Thierry and the original reviewers that the breaking change had
| minimal impact was proven wrong. 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.
|
| Overall, it seems the process is working quite well, and it is
| only the author of this article that is trying to bully his way
| into the discussion and ignore the context, with a very anti-
| hacker attitude of "if it kinda works, we shouldn't change it
| in any way", which is very much against the spirit of Emacs.
| froh wrote:
| thank you for this down to the facts summary.
| mixedmath wrote:
| This extra context is very informative, thanks!
| Y_Y wrote:
| Makes me wonder why they didn't decree, "no using a register
| called ^g, that's a special character" and add a check when
| specifying a register. I bet it would break fewer workflows.
| medstrom wrote:
| Well, exceptions for C-g shouldn't have to be hardcoded
| everywhere, because that makes it harder to move the C-g
| behavior to some other key. If going this route, I'd first
| implement a list of "keys with C-g-like behavior" that can
| be given more members than just C-g, via a startup flag or
| some such.
|
| Then commands could just reference that list if needed.
| tzs wrote:
| > 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. In
| particular, the universal Emacs cancel key, C-g, would not
| work here: instead, the text or position would be saved to a
| register called ^g
|
| I'm not very familiar with Emacs, so possibly stupid
| questions incoming.
|
| If you start to type C-x r SPC t to save to register t, does
| C-g work right after the C-X and the r?
|
| If so is that because the C-x, r, and SPC are part of the
| command sequence whereas the t is just an argument used by
| the command, and the C-g handling is done in the command
| sequence processing?
|
| Emacs is pretty famous for its flexibility in letting users
| bind and unbind key sequences to commands. Could people who
| like the old behavior fairly easily effectively restore it by
| unbinding the handler for C-x r SPC, and then bind handlers
| for C-x r SPC a, C-x r SPC b, C-X r SPC c, and so on for all
| registers they want to use, with each of those handlers just
| copying to the appropriate register?
|
| That should let them use the same keystrokes they now use,
| and if my guess above about C-g handling is right also make
| C-g work to cancel after C-x r SPC.
| jmclnx wrote:
| That is my understanding, and the change for v30 would very
| much annoy me also. I know nothing about lisp but I save items
| to registers all the time.
|
| I hope if this change is not reverted I can find a macro
| snippet that would do that extract key for me. Already in Emacs
| to do simple things involves lots of keys. Some I have created
| macros to avoid the keys, but I am not expert enough to create
| one for this change.
| krmboya wrote:
| Muscle memory should be elevated to a first class concern when it
| comes to emacs.
| atticora wrote:
| 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".
| bradleyjg wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| lvncelot wrote:
| 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 wrote:
| Attracting new users for with the old behaviour is too
| complex maybe?
| dromtrund wrote:
| Isn't named registers an advanced enough feature that it
| shouldn't be optimized for new users?
| samus wrote:
| 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 wrote:
| I believe Mozilla has been successful with a similar
| strategy.
| vcg3rd wrote:
| 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.
| morelisp wrote:
| 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.
| lstodd wrote:
| 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.
| nanny wrote:
| See: https://news.ycombinator.com/item?id=38592984
| mynegation wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| samus wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ginko wrote:
| 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 wrote:
| 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.
| dig1 wrote:
| 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".
| norir wrote:
| 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 wrote:
| 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/
| Jochim wrote:
| > 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 barriers
| to entry for new users.
|
| Many of emacs defaults are pretty awful at introducing users to
| the "emacs" way of doing things while also failing at easing
| unfamiliar users in.
| rightbyte wrote:
| 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.
| GavinAnderegg wrote:
| 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
|
| 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 wrote:
| Seems like that still needs an extra RET to confirm register
| overwrites:
|
| https://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
| GavinAnderegg wrote:
| 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 wrote:
| Thierry also already offered to add another option to fully
| revert to the old behavior:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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".
| cardanome wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Asooka wrote:
| 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.
| deng wrote:
| > They broke their users' trust.
|
| And now the drama is dialed to 11. I see no point in
| responding to such hyperbole.
| rollcat wrote:
| Context: I'm an Emacs user for 20 years...
|
| > There was a change committed which made using registers more
| friendly to use for newbies.
|
| ...and didn't realize this feature existed.
|
| > Maybe let's keep the drama down a bit?
|
| Agreed, this is non-news.
| lycopodiopsida wrote:
| The "maintainer" is Thierry Volpiatto, mostly known as author of
| helm, a completion framework.
| tarsius wrote:
| 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 wrote:
| I'm fully with you here; let the process happen and the
| discussion between contributors and maintainers happen before
| talking about "BAD NEWS".
| bachmeier wrote:
| 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 wrote:
| This is a pre-release commit not in any released version.
| Beldin wrote:
| Oh please. This is not someone's first step in an
| experimental new feature in its own branch. This is a
| commit of a fully working non-trivial patch that alters
| long-standing UI to the master branch. You're not supposed
| to merge in patches there on a whim.
| tptacek wrote:
| Do you do a lot of emacs development? I certainly don't.
| I'm trying to piece together who here is talking about
| the norms of the Emacs development team and who's talking
| about their opinions of how software engineering should
| work everywhere.
| tsimionescu wrote:
| 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 reviewer
| raised the issue and the patch author brushed it away
| somewhat, it fails to mention that the reviewer actually
| agreed with them afterwards.
|
| I think that the core problem is the article author saw a
| change that broke their workflow and didn't investigate
| any further for why it was made. They simply assumed they
| knew better and got annoyed that others saw some value in
| the original change. The very way it is presented in the
| article - as a change to add a confirmation for register
| overwrites - is a misunderstanding. The actual purpose of
| the change was to make C-g, the Emacs "cancel" key, work
| with register commands. The RET for confirmation was a
| side-effect, one which the author felt could actually
| have some value in itself.
| smaudet wrote:
| What I read (did not verify) was that two users discussed
| and decided on the feature. That's hardly a well
| deliberated change.
|
| I think for user facing features it makes more sense to
| provide new behaviors as opt-in, and go through a longer
| RFC period. Only if and when the new behavior is widely
| used and popular, then you flip the switch to default.
| _a_a_a_ wrote:
| Can you link to what you read please
| timmytokyo wrote:
| >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.
| jeremyjh wrote:
| > 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.
| rightbyte wrote:
| 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 ...
| nanny wrote:
| >If this has happened as described in the OP
|
| It's not. The article is bad and wrong. It preemptively tries
| to dodge such accusations, but most of the hyperbole and
| "emotions" are just downright lies.
|
| btw the person you responded to is the author of magit. I
| think his opinion should be weighted more heavily that the
| author of this article.
| jbluepolarbear wrote:
| That's a bad process. The review of the feature should start
| before it's merged into main branch, not after. It totally
| reasonable for people to be upset with a breaking feature in
| main branch without discussing it with the community at large.
| Changes merged in like this are how long standing tool lose
| community support.
| tsimionescu wrote:
| The review of the feature was happening in public on the
| mailing list. All those who contributed to that review had
| their concerns addressed, and the change was merged into the
| main branch (which is the development branch of Emacs). Only
| afterwards did others complain.
| jbluepolarbear wrote:
| The article says otherwise. It says that many concerns were
| disregarded during that time.
| heyoni wrote:
| Plenty of comments here saying that the change did more
| than make the feature opt in which is why it was
| rejected.
| yaantc wrote:
| The article is just his author view. Please read the
| emacs mailing list threads to get the full picture.
|
| GP is correct, and this is quite normal: some people
| using Emacs master will not follow all the mailing list
| discussions and commits. So they will notice a change
| only after it is merged. Nothing wrong with this, and
| nothing wrong with being unhappy about such a change.
| What's wrong in my book is the nature of the reaction
| show in this article (see my comment in reply to
| @tarsius).
| tsimionescu wrote:
| That's what the article says, but I checked the actual
| mailing lists. Any replies that asked for a change of
| this kind came in _after_ the patch was finalized. Even
| this author 's own complaints. And, the author in
| particular didn't understand, or seek to understand, why
| the patch was added in the first place. Instead, their
| proposed "fix" that they complain about in the article
| reverted all of the improvements the author and reviewers
| made. Upon being informed of this, they simply complained
| that those are useless changes:
|
| > Indeed, I only reimplemented the parts I saw as clearly
| beneficial. Most importantly, my patch improves stuff
| without breaking other stuff.
|
| > Perhaps you can explain your use case for the rest of
| the changes, and if there's a good and compatible way to
| add them I'll be happy to look into it at some point.
|
| > > - No filtering. > > - No navigation. > > - No default
| registers. > > - No possibility to configure a new
| command added to register.
|
| > If you could elaborate about these bullets, and explain
| their use, that'd be great.
|
| I think it's quite obvious that engaging further with
| someone who came in with this attitude after a review was
| finalized (after ~5-10 rounds of feedback, I should point
| ou) and a patch applied did not seem worth it.
| Y_Y wrote:
| Perhaps you could mention what these improvements are or
| give a link to the messages you're getting this
| information from?
| gray_-_wolf wrote:
| > into the main branch
|
| into the master branch
| eduction wrote:
| >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.
| aeturnum wrote:
| 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.
| achikin wrote:
| Here is the recap of someone is interested
| https://metaredux.com/posts/2023/09/09/clojure-support-in-
| em...
| yaantc wrote:
| Thank you @tarsius! Couldn't have said it better.
|
| To add, I have issues with the attitude shown by the blog
| author.
|
| If you use the development branch, you can't raise hell when
| there's a breaking change: it's to be expected!
|
| Then it's fine to disagree on some change and discuss this. I
| read the email thread, and I do not see "arrogance". Just
| strong disagreement. So yes, converging will take a bit of
| time... Calling publicly someone "arrogant" for not folding
| back to your view, and trying to raise the crowd (a good part
| of whom won't read the thread to make their own opinion) looks
| like bullying to me.
|
| Saying that his patch to make the change optional has been
| disregarded, when it was rejected because it not only made the
| change optional (that would have been OK, and a patch for this
| asked for) but removed other changes is not honest.
|
| Lastly, pointing out one person to blame when the whole
| discussion is done with the Emacs maintainers in the loop is
| also a no-go in my book.
|
| As a close to 30 years Emacs user, thank you to all its
| contributors! (and to Thierry, as long time Helm user) May
| their skin by thick, it's unfortunately sometimes needed :-P
| disruptiveink wrote:
| Eh. I don't think that argument holds water, unfortunately.
| Too often I've seen the "it's just a beta/unstable version,
| it's not finished, you can't raise issues like this!"
| attitude as an issue to shut down any form of discussion, or
| worse, to avoid having to think about the consequences of
| some action.
|
| Of course, nearly 100% of the times the behaviour people were
| complaining about will be part of the stable release. There
| is no magical moment where things just magically get sorted
| pre-release unless people voice feedback, especially if it's
| intended behaviour, as it's very much the case here. So call
| me jaded, when someone says "it's just the main branch, don't
| complain!" I just hear "I will do whatever I want and when
| the new release rolls in everyone will just have to deal with
| it." Which is totally fair if that's how you want to run your
| project, just don't pretend otherwise.
|
| An extra one, which isn't the case here but makes me roll my
| eyes every times it happens is the outrage of "how dare you
| raise an issue that was caused by a new pre-release iOS/MacOS
| version and very much seems to be an intended change in the
| OS behaviour, we don't support that!!", only for it to turn
| into the usual scramble "oh no, our software is broken on the
| new iPhones, who could have forseen this!!?" hours after the
| release version starts hitting the masses.
| yaantc wrote:
| There's a misunderstanding here: I'm not saying "don't
| complain". Complaining in itself is fine, and others are
| complaining on this topic in a way that looks OK to me (and
| will probably be more efficient too). It's the nature of
| this specific article complaint that I have a problem with.
|
| I agree with @tarsius on this: just give the discussion
| (and patches) some more time, and it's likely to end just
| OK from past experience.
| achikin wrote:
| I wonder why wasn't this patch given time before merging
| it? Isn't that the whole purpose of patches and merge
| process?
| Y_Y wrote:
| > Calling publicly someone "arrogant" for not folding back to
| your view, and trying to raise the crowd (a good part of whom
| won't read the thread to make their own opinion) looks like
| bullying to me.
|
| Isn't this a bit of a loaded take too? I'm sure the author
| wouldn't agree that what they wanted was for Thierry to "fold
| back". I agree with your criticisms here in direction but not
| in magnitude, in fact it appears to me like you're comitting
| the same sin of misrepresenting your opponent to enhance your
| position.
| yaantc wrote:
| That could be, the author may not have expected nor
| intended the exposition of an HN post. If so, my apologies.
| I still find the article unfair and biased in its
| presentation, compared to the email list discussion. It's
| unfortunate, because if one look the comments here it's
| clear many take the article at face value and haven't read
| the list thread.
| Ferret7446 wrote:
| I disagree. The Emacs community has, at least historically,
| strongly valued backward compatibility. Breaking existing users
| is just about the worst thing you could do in Emacs.
|
| If we aren't strongly considering reverting a breaking change
| immediately, that signals that the Emacs devs no longer value
| backward compatibility as highly, which means Emacs is
| abandoning many of its existing users.
|
| https://www.murilopereira.com/the-values-of-emacs-the-neovim...
|
| Core values matter. The Emacs maintainers did something that
| violated a core value, and the community is rightfully
| offended.
| mtraven wrote:
| 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 wrote:
| You must have missed the part where this change does not
| include the ability to revert to the old behavior via any
| settings.
| morelisp wrote:
| 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 wrote:
| 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.
| mediumsmart wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| smarx007 wrote:
| 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/
|
| [2]: https://yhetil.org/emacs/87r0k2pgq6.fsf@posteo.net/
| Kwpolska wrote:
| Is it just me, or is Emacs much more drama-prone, compared to
| Vim, VSCode, or any other text editor?
| akarve wrote:
| I was sure to read "the forces of vim have invaded our
| headquarters and now hold our CEO hostage."
| accelbred wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-10 23:01 UTC)