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

Advanced Linux user: “Ctrl-Z dammit fg”

      • Phil
        41•1 year ago

        And then you do it in a web browser and open developer mode

        • @[email protected]
          5•1 year ago

          Happens to me all the time 😅

          And since I’m already holding down ctrl I’ve formed a habit of using ctrl + shift + v even though just regular ctrl + v works. Although for me it’s mostly positive as I usually just want the text without formatting anyway.

      • @bigboismith
        6•1 year ago

        Ctrl+shift+c is also a shortcut to call in Teams. Ask me how I know.

  • @[email protected]
    19•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.

    • Orbituary
      19•1 year ago

      Omg. I’ve hated emacs for 30+ years and you just made it worse.

      • @Nibodhika
        10•1 year ago

        It sounds confusing, but it’s actually really easy to get used and hard to walk away from it. Essentially the undo is just another operation so it can be undone just like everything else, and that’s a redo. Imagine the following situation, I wrote a text, but wasn’t happy with some part, so I select that part and delete it, now I keep writing but I realised I need some part of what was there, so I undo all of the text that I wrote, select the text I want to copy, and accidentally cut it instead of copy it. In most editors that’s it, you’re fucked, you just lost your most recent changes, on Emacs undo does not destroy things, it only adds to the sequence. In other words, as a step by step:

        1. Write text
        2. Delete part of it
        3. Write more text
        4. Undo step 3 (most editors that means go back to step 2, so step 4 is in a dangerous space)
        5. Undo step 2 (again, most editors would have actually gone to step 2)
        6. You’re now in something that looks like step 2, cut the text you wanted (on most editors because you were in step 2 and did changes you can’t ever go back to step 4, because this is the new step 3 and there isn’t still a step 4, so undo and redo will undo and redo the cut of that text)
        7. Undo step 6 (you’re now similar to how you started step 6 or 2, on most editors you are really on step 2).
        8. Undo again (on most editors that would take you to step 1), this will take you to step 5, i.e. you redid the step 2, so the text disappeared and you’re like you were at the beginning of step 3.
        9. Undo again and you undo the undo of step 3, putting you back on original step 4

        Like I said, confusing to understand, but it means that you can’t ever shoot yourself in the foot by undoing things.

        • @[email protected]
          4•1 year ago

          Emacs’s undo-tree – which I mentioned above that I use – also provides non-destructive undo, same as emacs’s base undo. So you can’t lose data by undoing things. However, it also uses the undo and redo semantics to traverse one branch of the tree, so it works like most other apps as long as you aren’t needing to recover data that would normally have been “lost” by performing an undo.

          There are probably faster ways to do it, but since I rarely need to quickly grab stuff that an undo destroyed, I haven’t looked into them.

          1. Do non-undo operation.

          2. Undo it.

          3. Do non-undo operation. At this point, in software packages that lack non-destructive undo, you will have lost the data in #1.

          4. Run undo-tree-visualize, on C-x u by default. A new window will come up displaying the undo history as a tree.

          5. You can traverse around the tree. Move to the node immediately before the branch that you abandoned, and use C-b and C-f to switch between branches.

        • Orbituary
          2•1 year ago

          Yeah, no.

          If ‘esc-u’ doesn’t work, I :q!

          ,

          • @[email protected]
            5•1 year ago

            I will bet that vim has some form of non-destructive undo as well. Might take an add-on package, but generally-speaking, useful behavior in emacs and vim tend to get ported to each other.

            googles

            Yup.

            https://learnvim.irian.to/basics/undo

            In Vim, every time you press u and then make a different change, Vim stores the previous state’s text by creating an “undo branch”. In this example, after you typed “two”, then pressed u, then typed “three”, you created an leaf branch that stores the state containing the text “two”. At that moment, the undo tree contained at least two leaf nodes: the main node containing the text “three” (most recent) and the undo branch node containing the text “two”. If you had done another undo and typed the text “four”, you would have at three nodes: a main node containing the text “four” and two nodes containing the texts “three” and “two”.

            To traverse each undo tree nodes, you can use g+ to go to a newer state and g- to go to an older state. The difference between u, Ctrl-R, g+, and g- is that both u and Ctrl-R traverse only the main nodes in undo tree while g+ and g- traverse all nodes in the undo tree.

            Undo tree is not easy to visualize. I find vim-mundo plugin to be very useful to help visualize Vim’s undo tree. Give it some time to play around with it.

            It sounds like vim+vim-mundo and emacs+undo-tree operate kind of similarly, actually.

            EDIT: In fact, this is definitely the case. According to emacswiki, emacs’ undo-tree is based on vim’s model.

      • @[email protected]English
        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
          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.

          • @[email protected]English
            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.

            • Orbituary
              1•1 year ago

              This is my preference. Is that not OK?

              • @[email protected]English
                0•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.

    • Chewy
      2•1 year ago

      Undo-tree is awesome but it’s sadly not implemented in most editors.

    • @[email protected]
      15•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
        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