Beginning Linux user: “Ctrl-Z is undo, right?”

Advanced Linux user: “Ctrl-Z dammit fg”

  • tal@lemmy.today
    221·
    1 year ago

    In emacs, C-_ is undo. If you perform a non-undo operation, then undo it, then do a non-undo operation, then two undos will undo the undo.

    Unless you’re using one of emacs’s alternate undo systems, like undo-fu, undo-tree, or vundo, which may have their own ways of doing things.

    I use undo-tree, and with the default bindings there, there’s an undo on C-_ and a redo on M-_; undo doesn’t undo undos there.

      • sping@lemmy.sdf.orgEnglish
        1·
        1 year ago

        Bizarre that you’ve hated it for 30 years yet didn’t know one of the earliest things users learn about it (that actually is fine to use). Perhaps you should examine why you hate something you’re almost completely ignorant of.

        Though most jokes and criticisms about Emacs betray complete ignorance of it, so you’re hardly unusual.

        • Orbituary@lemmy.world
          1·
          1 year ago

          I don’t need all the overhead. Vi has always worked for me. It’s ubiquitous. I’m fast with it. It suits my needs fully.

          • sping@lemmy.sdf.orgEnglish
            2·
            1 year ago

            You must truly loathe vscode etc then if you hate emacs for overhead. I can’t really see why you should hate something just because it uses a slightly less small amount of resources. I don’t even know how you’d notice on any machine from the last 20 years.

              • sping@lemmy.sdf.orgEnglish
                1·
                1 year ago

                Seems pretty reasonable that if you want to tell the world you hate something, you might want the world to understand why you hate it, or else perhaps we might assume it’s not a reasoned position. That’s certainly the conclusion I’m coming to.

    • tal@lemmy.today
      17·
      1 year ago

      Control-Q

      Or you can disable software flow control in cooked mode with stty -ixon and then Control-S won’t suspend flow.

      EDIT: If you use screen or tmux, I suppose that you probably don’t need software flow control anyway from a UI standpoint, because both will suspend flow if you enter their copy mode, which acts similarly.

      EDIT2: I suppose that the utility of software flow control is probably rather reduced today from its original role. At one point in time, the rates at which data could be sent to the terminal was low enough that it wasn’t a particularly large issue to suspend it while interesting information was still on the screen. I certainly remember some relatively-slow terminal systems, especially with control sequences mixed in; BBSes took advantage of the fact that it took time for ANSI art to be transmitted at 9600 baud modem connections or so to make the display of an image something of an animated, vertically-scrolling banner; you’d have banners that were rather vertically-larger than the typical display, but moved slowly-enough to watch as they scrolled by. But today, a large chunk of software can throw text at the terminal so quickly that, unless its performance is otherwise-constrained, one has little chance of stopping flow while the information one wants is visible. Only really useful if the software naturally has stops at useful places and one can suspend flow there, and I don’t know what percentage of cases that comes up with. Maybe there’s an argument to default to not having software flow control any more.

      • vector_zero@lemmy.world
        2·
        1 year ago

        Bonus when you disable software flow control: In addition to Ctrl+r to reverse search through commands, you can search forward via Ctrl+s