*Fuck editors this is the ultimate battle*

I don't make so many fucking mistakes that I need a fucking TREE in my editor. I use git for that. Your retarded tree up your ass is just unnecessary bloat which should belong in the VCS.

I scoffed at the idea, too, so I don't blame you if you dismiss this as Emacs cultism, but trust me when I say there is a tremendous difference between a redo and undoing an undo, and it radically changes your workflow.

Can you explain why it's better than just integrating an existing version control system into an editor?

I'm not sure how I point out this irony without being a dick, but this "tree in your editor" is the way undo/redo works; in contrast, Emacs' undo and any text editor or software that can undo undo's has a completely linear undo path.

I would disagree. undo/redo is list, not a tree.

Well, I don't know what to say other than that's wrong. Unless you're describing only undo and you've got your words mixed up.

With an undo/redo paradigm, it's very easy to accidentally prune entire redo paths by undoing actions and then making edits.

With only-undo, all your edits are recorded in the undo list, including undos themselves, so you redo by undoing again. This is why you will never lose any state your file was in with only-undo. The downside of this is that, in order to go back to a very far-off previous state, you have to enter more undos than you typically would, but, in Emacs at least, this is ammended by Emacs' numerical prefix and various other modules that you can use to query your undo path with fuzzy search and regexp and any other search method you can think of, probably.

Sure looks like a list to me. In pic related notice how when we undo we go back a node and when we redo we go forward a node.

Attached: Oekaki.png (500x250, 8.51K)

It's more like this. See? You're confining yourself to this linear plain. I may have implied it, but I take it back now: the undo/redo paradigm isn't technically inferior to only-undo--just different. But it doesn't mean the two aren't fundamentally different.

Attached: Oekaki.png (500x250, 87.4K)

There is no way to go back to the D node anymore.

Attached: Oekaki.png (500x250, 5.31K)

vim's undo is a tree. Look into what 'g-' does. It lets vim provide the advantage of quick undo/redo without the risk of losing work. Provided you understand it.

Exactly! Now you get it. But in most contemporary editors, there are tools that will help you manage these undo trees, so it's not really a problem, just not as elegant.

CMD+Z

Seriously, why hasn't this caught on? The super key is barely being used on most DEs.

i actually like ctrl + shift + z, but i rather press u to undo

oh damn that's cool, I think i know how it works

It's really uncomfortable to hit the super key though.

Because the whole point of the Super key is that keybinds for your WM don't overlap with popular keybindings for other applications, idiot.

buy a mouse, 'tismo

Oh, you're this kind of faggot. I suppose clicking on the undo/redo buttons might be better for you.

youtube.com/watch?v=n0tFZZmkGLg

...

shift is used more elsewhere and carriers a connotation of shifting direction.
ctrl-z undo, ctrl-shift-z redo
alt-tab next window, alt-shift-tab previous window
tab next element, shift-tab previous element
etc.

If x does something, shift-x should do the opposite.

No, retard, when shift key is active the 6th bit of the character is cleared, meaning the character set is 'shifted'.

I don't see the relevance.

Thank you for this. It's kind of the same for Emacs, where Meta is a larger version of its Ctrl counterpart, and Ctrl-Meta as a superset of the two.

This. u and C-R are best complements. Also, U and u, for when you leave capslock on or when you try to insert a capital u but aren't in insert mode.

this
ctrl-y is retarded

also

good luck OP

Firmly behind ctrl-shift-z after reading this. Ctrl-y fags need to be purged from FLOSS communities and an empire of consistent redoing in GUIs established.
I'm OP btw

If your editor cannot handle regional undo, trash it.