17 ms·

Resolving the great undo-redo quandary

• sharikous 4y ago
  My way is a a ugly undo - copy - redo - paste. Not efficient, sure, but I'm used to it and it solves my problem most of the time
  • twodave 4y ago
    Honestly IMO it's a bit better--often times I find myself wanting neither _this_ nor _that_, but some of each. I get to a point in a function where I realize changes I made elsewhere are no longer needed, but I want to keep my function the same. So I usually just copy the function (and paste it someplace so I don't for real lose it), undo everything, then just splice the function back in how I want it.
  • somebodythere 4y ago
    The main issue with this I find is a stray keystroke before you redo wiping your redo stack .
    • phendrenad2 4y ago
      I solve this by making a git commit before diving into the undo.
• jtaft 4y ago
  Sounds similar to vim’s time travel command :earlier 30m
• pwpwp 4y ago
  Would be useful if this had a comparison with Emacs, which also resolves the GURQ.
  • jefftk 4y ago
    Emacs already implements exactly what they are proposing: an undo operation is just another action added to the chain of states, which can itself be undone.
• rcthompson 4y ago
  This is exactly how undo works in Emacs out of the box. Personally, I prefer to install the undo-tree package and manually browse through the tree of undo paths. I'm not sure why this author finds a tree unacceptable for this purpose.
  • rtpg 4y ago
    Because it requires more than two commands
  • gpvos 4y ago
    And it is exactly why I find Emacs undo so hard to work with. But maybe I will get it now I've read this article.
    • tmtvl 4y ago
      You can, if you like, install the 'vundo' package, which gives you a tree-based overview of your undo history, making it easy to switch between branches and go backward and forward. It's basically like the undo-tree view for the default undo mechanism.
    • b3morales 4y ago
      Two suggestions that might make it easier for you. There's a package called `undo-fu` that puts a thin layer on top of the undo system to keep the behavior strictly linear. And built in, there are the `undo-only` and `undo-redo` commands. Unlike the base `undo` they will only walk in one direction.
    • BeetleB 4y ago
      Note that Emacs undo is not tree based, but works as described in the article. The tree based undo is a separate package one has to install.
      • gpvos 4y ago
        As I wrote.
    • 4y ago
• adrianmsmith 4y ago
  The !Edit text editor in RISC OS used this algorithm in the late 80s. https://www.databasesandlife.com/risc-os-edit-undo/ https://www.databasesandlife.com/risc-os-edit-undo/ I must admit I found it a bit confusing at first. Took me quite a while to form a mental model of how it worked.
• heeen2 4y ago
  I implemented something similar for a interactive whiteboard project once. The undo operation would simply be appended as another action that itself could be undone by re-doing it. However, as you played with it, it became confusing because it ran counter to ingrained expected behavior of an undo/redo dual stack implementation. Eventually I implemented the classic approach.
• asciimov 4y ago
  > No, there is no undo "tree"[...] This is still a tree, it's just implemented in an array.
  • vitiral 4y ago
    This is still an acyclic node graph, it's just implemented as a tree.
    • preordained 4y ago
      yep, it's graphs all the way down
  • andybak 4y ago
    Wll, it's a tree that is collapsed into an array - which makes it an array to all intents and purposes. The point is that the "tree-ness" is never exposed to the user. This is the problem OP is claiming to have solved - the cognitive burden that the tree solution introduces.
  • rdez6173 4y ago
    The point is that the "tree" is not exposed to the user. I feel the author makes this extremely clear.
  • guipsp 4y ago
    Yes a linked list is a degenerate tree, but was this worth pointing out?
• Veuxdo 4y ago
  Sounds like the Braid version of undo-redo.
  • adrianmsmith 4y ago
    Could you elaborate or provide a link? I haven't heard of the "Braid version of undo-redo" before.
    • aidenn0 4y ago
      Braid is a video game with time travel as a core mechanic
    • vitiral 4y ago
      Braid is a game about time travel. This is not like Braid at all, since the game works by "overwriting" your past actions (with a few other mechanics). The Braid editor would be like "Normal" undo except a ghost cursor continues to make the edits you just undid. Would be a hilarious April fool's feature.
    • pmarreck 4y ago
      Even if you think you don't like games, Braid was really different
    • Kwpolska 4y ago
      I guess they’re referring to https://en.wikipedia.org/wiki/Braid_(video_game) https://en.wikipedia.org/wiki/Braid_(video_game)
  • DonHopkins 4y ago
    Game Helpin' Squad: Time Travel Understander https://www.youtube.com/watch?v=1fABGyVzVwI https://www.youtube.com/watch?v=1fABGyVzVwI [Braid parody tutorial]
• gandalfff 4y ago
  Alternatively, use Vim undotree: https://github.com/mbbill/undotree https://github.com/mbbill/undotree
  • Asooka 4y ago
    Or the earlier / later commands which function exactly as the article describes and are part of vanilla vim. You can even give them a time argument, for example :earlier 10m to go back ten minutes.
  • andybak 4y ago
    I found the article interesting because it's an approach that I could apply to tools other than text editors - it explains the general concept. I wouldn't have discovered it if someone just posted a link to a Vim add-on.
• aliswe 4y ago
  Genius.
• deleted 4y ago
  [deleted]
• indosauros 4y ago
  FYI if you use Jetbrains/PyCharm, it also provides this (and has saved me many times) Just right click your file and view "Local History"
  • jasonjmcghee 4y ago
    Yup. And it's full-text searchable, which I've found people generally don't realize. Fantastic feature.
• 323 4y ago
  Many times I want to undo to a previous state, but then apply again a few of the changes I just reverted, basically cherry-picking from the future (from the redo stack). It would be interesting to be able to see all edits as individual patches/diffs that you can commit/discard individually. Like a mini automatic git inside the editor, automatic in the sense that every "edit" creates a commit, undo/redo move HEAD. This would be entirely optional, you can continue using Undo/Redo as usual, but if you need to do a more complex history operation you can open this "git" view and operate on the edit tree directly. Photoshop has this nice undo panel where you can see individual edits and click your way to the desired point in history: https://www.bwillcreative.com/wp-content/uploads/2020/08/how-to-undo-and-redo-in-photoshop-18.jpg https://www.bwillcreative.com/wp-content/uploads/2020/08/how... One can imagine such a view in a text editor, where each entry shows a diff of what that step did.
  • spullara 4y ago
    Use local history in any JetBrains IDE.
    • JackFr 4y ago
      And with the diff panel you can easily cherry pick selected changes to apply.
    • jasonlotito 4y ago
      Seriously. This is one of those features I forget other people don't have access to. Anything less is just uninspired.
      • 323 4y ago
        VS Code has this feature too, it's just not known.
    • bitslayer 4y ago
      I am not a JetBrains user, but it looks like that only applies to saved versions? Undo normally holds every typed change. https://www.jetbrains.com/help/idea/local-history.html#restore-changes-from-local-history https://www.jetbrains.com/help/idea/local-history.html#resto...
• jovial_cavalier 4y ago
  Vim supports this out of the box with :earlier and :later
  • maxk42 4y ago
    And g+ / g-
• lichtenberger 4y ago
  You can do this with a tree-based persistent/functional data-structure, too. For instance the single writer (per resource) in the evolutionary, append-only database system[1], I'm working on in my spare time, can simply revert the whole resource (resource is like a table in the relational DB jargon) to a past revision. Once a new commit is issued a new revision gets appended and the whole history in-between is preserved. Thus, you can, for instance, retrieve individual changes and cherry pick these from the revisions in-between. [1] https://github.com/sirixdb https://github.com/sirixdb
• ctrlmeta 4y ago
  > No, there is no undo "tree", nor any complicated graphical user interface to go with. ... You've got your undos, your redos, and that's it. The underlying data structure is strictly linear, but all edit states are preserved and reachable ... This is exactly how Emacs works! Emacs has worked like this since its beginning in 1980s. It was even documented in the first manual (1981): This might seem to pile one disaster on another, but it doesn't, because vou can always Undo the Undo if it didn’t help. (page 137 of manual) I think there needs to be some sort of computing and software history lessons. It can offer great value in the current world of software development. It will save you from the trouble of rediscovering techniques that are already in use in classic battle-tested software. (And really? You need to invent a cheesy acronym for this? If that's what it takes to sell the obvious these days, how about SLUR - Simple Linear Undo Redo?)
  • vitiral 4y ago
    Of course emacs implements it as just a long linked list.
    • coldacid 4y ago
      It doesn't need to be anything else.
  • nerdponx 4y ago
    Vim also has an undo tree, although you need a plugin to work with it easily (called "Undotree").
    • zwkrt 4y ago
      Yes but the article is specially calling out that using an undo tree is something no one wants.
      • lostcolony 4y ago
        And that you still want a linear path through your undos and redos...and that's something that Emacs does.
• cletus 4y ago
  The best form of history, undo and redo I've used is on hte various Jetbrains editors. It's a feature called Local History and is insanely useful. 1. It's always on. It never requires an explicit save or commit; 2. It automatically saves any changes and timestamps them; 3. You can view the state of a file or a tree at any moment in time and then pull out that file (or tree). 4. If you do that, it becomes part of the temporal history so you can always go back. I find this completely natural because usually when it's necessary you think "Oh I need to unwind most of what I did in the last hour" or "I changed something I shouldn't have yesterday". You're not thinking about a line (or a tree) of changes. You're thinking about times and possibly ordering ("I changed X right before I changed Y").
  • 323 4y ago
    VS Code has that feature too, but only for individual files.
    • alisonatwork 4y ago
      I wish VS Code would expand on that feature, coming from IntelliJ. It's really annoying that you need to type the name of the file you want to see the local history of, even when it's the currently active file in the editor. There should be a sidebar widget for it that's active for whatever the current file is. The cool thing with IntelliJ is if you accidentally deleted a file you can just touch a blank version of the file and the history comes back. Not sure if VS Code does that yet.
      • 323 4y ago
        There is a sidebar widget. But it starts merged in the File Explorer view, and you need to drag it over from there to the sidebar to make it independent - https://stackoverflow.com/a/71522634 https://stackoverflow.com/a/71522634 The widget is called "Timeline". > The cool thing with IntelliJ is if you accidentally deleted a file you can just touch a blank version of the file and the history comes back. Not sure if VS Code does that yet. VS Code does keep the history after file deletion, but I'm not sure how to access it from inside. I had to manually rummage through the storage directory to find a file I accidentally deleted, but it was an file which was never saved (think Untitled), so it didn't had a path that I could try creating a blank file at.
• quartz 4y ago
  Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original state while making sure not to accidentally execute any inputs which would burn down the redo stack.
  • vvillena 4y ago
    Jetbrains IDEs can do this using the local history feature. Browse through time on a separate tab, copy what you need, and paste it back into the present.
    • Larrikin 4y ago
      Whats even more amazing is that you can right click the package/folder and get local history and see entire files that you previously deleted. Took me a while to discover this but has saved me almost as many times as local history in a file. Also makes me feel much better when refactoring and deleting tons of old code.
  • headPoet 4y ago
    A lot of IDEs (I know Eclipse and VSCode both do this) will create a copy of the file you're working on each time you hit save. You can then navigate back through the local history of the file. I'm conditioned to hit Ctrl+S with almost every change, so this gives me a very detailed history of my revisions.
  • lelanthran 4y ago
    Vim stores all deleted text automatically, up to a max of 10, I think. Probably very possible to extend that with some advanced vimscripting.
    • cpcallen 4y ago
      In this thread: people discussing all the excellent features they wish their text editor had that emacs (and/or vim) has had for literally decades.
• ec109685 4y ago
  In this methodology, without exposing the tree, how does the user select between the two branches created after the butterfly is squashed? It seems like Google Docs does it in an intuitive way where undo / redo works normally, but there’s another time ordered history of the document to select from. Is this what the author’s approach is advocating?
  • zwkrt 4y ago
    In the author’s algorithm there is no two branches. The following diagram is an undo tree where we made change B, went back to A, then made C C ——— now / —— A \ B But time doesn’t branch, so our history shouldn’t /have to/ branch. What if our undo was itself part of the linear history? Then we could build up the history like this: A A —— B A —— B —- undo_B A —— B —— undo_B —— C For complex undo/redo scenarios this could get out of hand. A — B — undo_B — C — undo_C — undo_undo_B —undo_B — undo_A… But the author (I think correctly) states that for the average user this behavior is intuitive and desired. They also added the optimization that undoing and then redoing a set of changes doesn’t make it into the history, as it’s basically a no-op.
  • kdmccormick 4y ago
    Nope, the author's solution is to consider the original undo (the "time travelling") to be an undo-able change in itself. No branching history. So you end up with: state 1 * change A state 2 * change B state 3 * undo B state 2 * change C (the "butterfly squashing") state 3a * undo C state 2 * undo <undo B> state 3 (!) * undo B state 2 * undo A state 1 The traditional editor would differ by putting you right at state 1 at (!), blocking your access to state 3.
• unholiness 4y ago
  Feels like I'm missing something... If I press ctrl-z ctrl-z, I expect the last 2 things typed to be undone. Based on what he's saying, the first ctrl-z undoes one step, and the second ctrl-z undoes the undo i.e. puts me back where I started, with no way to get back further. Is there a special case for multiple undo's in a row? If so it seems unclear where to draw the line. If not it sounds nonfunctional.
  • dmix 4y ago
    True, at what point do you include the undo itself in the undo history or do you skip it entirely? Never considered that.
    • osrec 4y ago
      I feel things work most intuitively if the undo/redo functions simply navigate the history, but do not themselves form part of the history.
      • unholiness 4y ago
        That's how every other undo works. The whole GRUQ is caused by undos not themselves forming a part of history...
        • TuringTest 4y ago
          That's it. You can think of an undo operation U at time (t) as a new simple command that rolls back the content to a previous version (t-x). If you undo that U operation, it's a new command U' that restores content again to version (t). The history sequence would then be: (t) --U-> (t-x) --U'-> (t) And if you add (A) some new content (c) when in state (t-x), it becomes command , which can itself be undone with commands U'' (to remove A), U''' (to remove U): (t) --U-> (t-x) --A-> (t+c) --U''--> (t-x) --U'''--> (t)
        • hackmiester 4y ago
          >every other undo Ahhhhh, some time you should try a little app called Adobe Photoshop.
• samatman 4y ago
  There's an interesting parallel here: the system proposed in the post is concatenative, and the undo tree style is, well, a tree. Sort of a Forth v. Lisp thing. Here the big disadvantage of Forth, the implicit stack state, is less obviously balanced by something good. The UX of undo trees could certainly use improvement, it would be great if undo/redo behaved as expected, but any pivot point would automatically pop up the tree view. Then there's cherry-picking, but I have a solution to that. This is in fact the thing I want most from an editor: select a region and then undo/redo changes only in that region. Search and replace tends to work this way, but I've never seen it in an undo/redo system. How many times have you modified a function, broke it accidentally, and just didn't notice and made more changes? So the tests go red, you run a diff, and you see exactly what needs fixing: but you copy and paste out of the diff, because you can't just undo within the offending function.
• chrisshroba 4y ago
  I disagree that undo and redo are the only two actions needed to support this behavior. For example, if I’m performing the following three actions: - insert A - insert B - insert C And then I undo, I would expect to be be back at having AB. If I then undo, I would be undoing my undo and have ABC. Then undoing again would get me back to AB. And I remain in this 2-cycle. Instead I propose the best solution is to be able to “step out” of the editing experience and see your history in a separate UI, and be able to choose a specific past version to revert to. This revert would be an atomic operation that could then be undone. This is how most versioned consumer systems I know of work today (e.g. Google Docs, Figma, MS Office) and it feels intuitive to me as a user.
• randomsearch 4y ago
  Relatedly, have you ever thought about how undo works with text? Open your mail client, compose a message, type a few words. What do you expect cmd-z to do? How much of the words will it undo? All the line? Try it. Then after undo, type a bit more. Hit enter and cursor back. Type again. Undoing typing is no trivial matter.
• stevebmark 4y ago
  Plug for the Vim undotree plugin, which exposes Vim’s undo tree in a navigable UI. It’s saved my butt in the rare occasion I need it. https://github.com/mbbill/undotree https://github.com/mbbill/undotree
• pierrebai 4y ago
  This doesn't solve the problem of wanting to redo from another "do history branch" while preserving the changes you've done in your current history branch. Using the notation of the article, you have done: A -> B -> C -> rewound to B -> D -> E Now at that E point, you'd want to have C too. (I'm assumikng there is no conflict between C and E.) There is no point in the linear history where you have both E and C. Sure you can go back to C, or go back to E. Or go back to C then decide to go back to E again. But you can't have both. In vim, I use the fact that the yank buffers are not part of the undo/redo history, only changes to the file are. So I undo to the point I had the change I want back, yank them in a named buffer, redo and put the yanked buffer. You cannot go to an alternate history, but at least you can get back stuff you've deleted. In git, what I describe is pretty-close to cherry-pick from a commit in a branch you deleted that you find using the ref-log.
• Strilanc 4y ago
  > you can use up all available memory in approx. 64 quick steps by: Type 1 character; Undo to beginning; Type 1 character; Undo to beginning; etc This is fine because "undo to beginning" isn't a single action. Each time this loop runs, the user spends more and more time mashing undo to get back to the beginning. The number of actions in the history is only increasing by a constant amount per user action.
• Izkata 4y ago
  Vim has this, it's :earlier and :later https://vimtricks.com/p/vimtrick-time-travel-in-vim/ https://vimtricks.com/p/vimtrick-time-travel-in-vim/ :earlier 3 – Undo the last 3 changes :earlier 5m – Go back to the state of the file 5 minutes ago :later 2 – After undoing something, redo the next 2 changes :later 1h – Travel forward through the change history 1 hour Vim also stores the tree of changes, but it's a pain to access without plugins.
  • bigfatfrock 4y ago
    Using strictly vim for years, I'm still mind blown by the sheer amount of "don't knows" within the tool that I miss like this. Thank you!
  • fnfontana 4y ago
    I have started to learn Vim about a year ago and still learning new tricks each day
    • hackmiester 4y ago
      Wait until you say this after 10 years.
      • vintermann 4y ago
        After 10 years he might even be as fast as with a non-modal editor.
        • Ar-Curunir 4y ago
          Every non-modal editor I’ve used is significantly slower at editing text than Vim
          • vintermann 4y ago
            We have been through this argument many times. Here's Tog at Apple in 1989: https://www.asktog.com/TOI/toi06KeyboardVMouse1.html https://www.asktog.com/TOI/toi06KeyboardVMouse1.html And even then, it was old news. There was behavioural research in the 70s, the same kind that was used for designing cockpits (and which saved lives), showing that modal interfaces were undesirable. It can well be that you're a god with vim. But odds are, then, that you could have been a god with modern CUA-derived interfaces too (or with Emacs) if you'd put similar effort into it.
• DonHopkins 4y ago
  Then there's Undo/Redo for navigating relationships (1994, interactive music video, Macromedia Director, Mark Canter, Meet MediaBand, UnDo Me): Meet MediaBand (2/5) - UnDo Me https://www.youtube.com/watch?v=8E-Sc9XafmE https://www.youtube.com/watch?v=8E-Sc9XafmE >The second of two interactive music videos on Canter Technology's Meet MediaBand CD-ROM, UnDo Me could very well be considered the "Choose Your Own Adventure" of music videos - in that MediaBand's lead singer, Kelly Gabriel, has to choose from one of four different relationships. YOU help Kelly decide which one to try, and navigate her way through each relationship. >At the end of each chorus, you are asked to make a branching decision based on whether Kelly should be passive (ice) or aggressive (fire) with the guy she's going out with. Things not turning out well for her? At any time you could "UnDo the past" and choose a different guy, or even jump back to a certain point in the relationship and change your decisions. >Four separate videos were produced for each relationship (concluding in a total of 16 possible outcomes), connected together with an intro, a home chorus and reverse/"UnDoing" sections. As you could probably tell each section has a different musical style, reflecting the mood and personalities of the relationship that section represents. A version of the song can also be found as a separate CD audio track on the Meet MediaBand CD-ROM. Meet MediaBand by Marc Canter (1994): https://www.youtube.com/watch?v=0dRZ52wM84Q https://www.youtube.com/watch?v=0dRZ52wM84Q https://www.ebay.com/itm/325099461299 https://www.ebay.com/itm/325099461299
• hamilyon2 4y ago
  Intellij enables multifile changes, renames, file moves with multiple files as single operation, as well as reload from disk, which breaks this simple linear history model afaiu. There is also a separate linear time-based local history in case you screw up. How intellij handles this is the best, in my mind, because of simplicity and separate "I screwed up" mode.
  • qw 4y ago
    "Local history" in IntelliJ has saved me several times. The diff mode is very useful when working on a piece of code and suddenly your tests starts failing and you need to find out what changes you made in the last hour.
• colanderman 4y ago
  JOE [1] has worked this way as long as I remember (which is close to 20 years). [1] https://joe-editor.sourceforge.io/ https://joe-editor.sourceforge.io/
• jasonjmcghee 4y ago
  I haven't seen `set undofile` mentioned yet- vim supports persistent undo. You can close a buffer, restart etc and when you reopen, you can still undo. I'm a huge fan.
• NelsonMinar 4y ago
  Lifestreams was based on the same core idea of keeping all past versions of a thing. Only with Lifestreams you keep all past versions of everything. I constantly find myself thinking back on these ideas from the 90s, there's a lot in Eric Freeman and David Gelernter's work that is worth revisiting now that storage is so cheap.
• dahart 4y ago
  > Second of all, there's no need to include "window shopping" in our recorded history; this is when you undo a ways, take a look around, then skedaddle out of there back to "the present" without changing anything. This is just a matter of moving information back and forth from undo-stack to redo-stack. Usually the whole reason I might undo for a while is to get back part of something I was working on and merge it into other changes I’ve made since then. I’m curious why the author dismisses this, personally cherry picking old history is my primary workflow with undo. In editors that support the undo history they’re advocating here, like emacs, I’m usually undoing a long way so that I can put something in the clipboard, then redo all the way back and cut-and-paste the previous partial state. It is nice in emacs that typing after undo doesn’t lose my undone edits, that is handy and is a nice little safety net, but it doesn’t actually solve the problem I normally want to solve.
  • dullcrisp 4y ago
    It doesn’t sound like you have a problem though. Just keep doing what you’re doing.
    • dahart 4y ago
      Hehe, sure, but there are better ways to do this, and it’s a common need. If the best thing we have is hitting undo 45 times to find something, copy it, try not to accidentally type anything and try not to accidentally lose the clipboard, then redo 45 times, then do a bunch of manual editing… now repeat the entire process for every file, when there are several involved… if that’s sufficient, then SVN is sufficient for source control, and we have no need for Git, right? ;) My real point is that the “Great Undo-Redo Quandary” is broader than what’s in the article, and the solution discussed is incomplete, doesn’t solve a big chunk of the reason people are using undo multiple times.
      • TheRealPomax 4y ago
        Is it though? If you really just needed part of what you had and hour ago, then there's nothing wrong with scrolling back to an hour ago, copying that one bit you needed, scrolling back some more to where you were a minute ago, and integrate it as desired? (which, note, is not window shopping: you didn't go back to have a look and skedaddle; the past is a data store, and you're accessing that data store for productivity reasons)
• SWEETCANDY 4y ago
  I am new player
• im3w1l 4y ago
  I absolutely detest emacs' default undo behavior. I find it worse and more confusing than the normal simple stupid algorithm. With undo-tree, it becomes better than normal, but only very marginally so. I use the linear undo and redo it provides every day but only go looking at the tree a few times a year.
• giancarlostoro 4y ago
  This reminds me of the time I nuked all my code by mistake (rm -rf *) and I still had PyCharm open, and I opened their "Code History" tool and un-deleted all my code, immediately proceeded to commit and push whatever state it was in because I was about to freak out. I think all IDE's should have their own internal copies of code that are housed elsewhere, it has saved me hours of turmoil trying to re-write already solved for code.
• bo1024 4y ago
  Cool! What about a model based completely on the "history" as a list of states of the document over time? There is no "undo" or "redo" operation, we only have "browse backward/forward in time". If you are browsing at a point in the past history, you can just start editing. Then the document state is copied to the end of the history (i.e. the current point in time), followed by your edits, etc. This removes the 2^n problem. It could be a bit inconvenient if you want to do a lot of tree-like changes, but could also better balance convenience+usability+power.
  • jsmith45 4y ago
    That is basically the same as the proposed skipping of B in navigation. It does however require the ability to put "make document look like X" (where X is the old state) as a single undo stack entry. If your app design allows that, great, squashing all of B into a single entry would work fine. Such an implementation would be: if you go back and try to make a change, it moves everything from the redo stack to the undo stack (to return the the "present"), adds one entry in that represents atomically changing the document to match the old state you were looking at, and then finally adds the change you attempted to make as a new entry in the undo stack.
    • bo1024 4y ago
      Hmm, I wasn’t thinking of implementing it as an undo stack at all. Anyway, the main difference I’m thinking of is UI and mental model we present, which I think could be a lot simpler here.
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• advisedwang 4y ago
  So, like Google Doc's document history? When you revert to an old version, it creates a new version with the old contents, it doesn't delete all the intermediate states. (although ctrl-z ctrl-y doesn't do this)
• cratermoon 4y ago
  As soon as I started reading the author's solution, I thought of git. Good to see it acknowledged later on.
• bhawks 4y ago
  Google's internal source repository client CitC (client in the cloud) behaves this way for your entire workspace, forever. It was so freeing - every single file save, delete, move and so on was saved without user intervention. Realize that you were barking up the wrong tree for 2 days? Simply go into .snapshots and the entire workspace from before would be there. This interface composed so well with other tools you could do a parallel bisection test across every prior state of your workspace and find the minute where you made an edit that broke some functionality. All on the cloud. I miss this tool very much. No amount of git commit discipline can emulate it.
  • ray__ 4y ago
    I'm surprised that tools like this aren't more common (even in non-commercial settings) given the tiny amount of space that code/text takes to store.
• bigmattystyles 4y ago
  So Back to The Future II basically :-) (edit below) (1985 Marty + Doc) => 2015 (2015 Biff) => 1955 => 2015 (he shouldn't be able to return here) (1985 Marty + Doc) 2015 => 1985' => 1955 => 1985
• low_tech_punk 4y ago
  Wow, the article nailed the UX. On the implementation side, I think the article implies that you might need to model the edits by Operation, rather than State? Otherwise, the cost of the undo scales O(N) of the content size, which is not viable. It works well for Git, which models content by State, using Structural Sharing. But Git has built-in delta compression so the memory footprint is roughly O(1) per operation. I don't think implementing this on the web for a <textarea>, or [contenteditable="true"] is a "minimum" effort. Challenges I can think of: 1. DOM api exposes state, not operations. You need manual diffing 2. When applying the operations, you need to manually restore cursor positions 3. CJK language IME might inject unwanted intermediate states that must be ignored
• pencilguin 4y ago
  It always astonishes me that undo, redo, and auto-save are implemented without relying on a logging mechanism akin to databases' "write-ahead logs". To me the main problem of maintaining "redo" actions is of identifying them. They are unnamed, and presenting and recognizing an alteration is hard.
• dsp_person 4y ago
  My biggest gripe with undo is in cases where it's unclear what undo will do if anything, and the action is file or email related without a clean redo option. Thunderbird - oops I just keymashed and did a bunch of random shortcuts. OK great I can Undo infinitely with no indication of what emails are being moved or undeleted, etc. Windows Explorer, Dolphin etc - undo can be pretty opaque unless you already know what it is that is being undone. And there isn't a redo! > Of course that tree requires a navigation system for users to pick their way back through the undo-redo history, leading to all sorts of complicated user interfacery that nobody has time to deal with. I would LOVE the complicated user interfacery to be in all applications to show at least the list of actions! Image editors are great at this.
  • mhb 4y ago
    Unbelievably, Solidworks does not even have undo for some things and undo/redo are terribly broken.
• xg15 4y ago
  Have to applaud the author on their naming game. GURQ is definitely one of the best worst acronyms.
• riccardomc 4y ago
  TL;DR So much cognitive load. Just configure Vim to put everything you delete in your clipboard and use a clipboard manager like diodon[1] with 1000 items. Of course works also outside of Vim, you just have to copy the part you might want to reuse before deleting/modifying. [1]https://github.com/diodon-dev/diodon https://github.com/diodon-dev/diodon
• siraben 4y ago
  I've been using undo-tree[0] in Emacs for several years now, and it's amazingly intuitive and fast to use and shows your undo history as a tree. [0] https://elpa.gnu.org/packages/undo-tree.html https://elpa.gnu.org/packages/undo-tree.html
• nathias 4y ago
  vim has :earlier 5min and :later 5min commands
• phendrenad2 4y ago
  Hmm, interesting, but I would actually like a different system (and let me know if any VSCode plugins implement this!): I want TWO forms of undo, one which actually undoes my changes, and one which only shows me a ephemeral view of the code in previous states. Call it "not really undo" or "viewing history but not changing it".
• Waterluvian 4y ago
  I want two things before retirement: 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard. Now I know some of you veterans will say, “there’s a plug-in for this! You just need to do these things…” no no no. I want this mainstream. Why are we living in the 1900s still?!
  • lolinder 4y ago
    > 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. I'm having a hard time imagining an implementation of this feature that would be faster than "undo, check what happened, redo if undesired". I can see a need to explore the whole history (JetBrains IDEs have the local history), but what benefit do you see from previewing a single step? > 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard. CopyQ is a great tool that does just this, available on Linux and Windows. I'm sure there's an equivalent for Mac. EDIT: also, not to plug JetBrains again, but their IDEs have clipboard history built in within the editor. I have CopyQ for system-wide clipboard history, so I don't bother with it, but it's there.
    • deleted 4y ago
      [deleted]
    • roryokane 4y ago
      For browsable clipboard history on macOS, I recommend LaunchBar (https://www.obdev.at/products/launchbar/ https://www.obdev.at/products/launchbar/; docs at https://www.obdev.at/resources/launchbar/help/ClipboardHistory.html https://www.obdev.at/resources/launchbar/help/ClipboardHisto...). I used to use the Clipboard Plugin of the free and open source app Quicksilver (https://qsapp.com/ https://qsapp.com/), which worked fine but was slightly less streamlined. Some people prefer Alfred (https://www.alfredapp.com/help/features/clipboard/ https://www.alfredapp.com/help/features/clipboard/).
• greggman3 4y ago
  there is much more to good undo than this. many editors collapse edits into a groups and you can only undo by groups, not individual keypresses. This is usually desirable. For example type X then cursor right 60 times then type Y then undo 3 times. Are you at 2 characters before where the Y was or back at the X or before the X? In other words, were the 60 cursor right keypresses collapsed into 1, 2 steps or not collapsed at all Good editors spend some time thinking about the most expected group definitions, bad editors (vscode in this specific case) seem to have picked a random number for their group size or a even a fixed number of keypresses but it feels random. There's no predicting how much it's going to undo in a single Ctrl/Cmd-z. Ii rarely does what I want compared to other editors
• Ferret7446 4y ago
  As another comment mentioned, this is exactly how Emacs handles undo, so this is not revolutionary. Two important things to point out about this approach: 1. you will never lose any previous information (barring memory limitations). You can be confident any previous state can be retrieved somewhere along the linearized history, and you don't need to search along a potentially thousand branched tree. Just follow the linear history and you will find it. 2. this tracks the chronological state of the buffer. For some reason, people do seem to get confused with Emacs's undo functionality because they're familiar with the "Microsoft Word" style undo, but I feel like it's intuitive if you think of it as a literal timeline of the buffer state. If you want the state of the buffer five minutes ago, you will need to undo past the one minute ago state, the two minutes ago state, etc. And then two minutes later, you can undo two minutes back to get the same state again even though the "original" state is now seven minutes ago, because when you "undid" you brought the buffer back to that state in the present.
• hddqsb 4y ago
  This sounds very similar to Emacs' undo history, except Emacs doesn't implement the "window shopping" optimisation. Instead, Emacs has a command `undo-only` which is similar to `undo` except it will skip over undo-redo chains. > Thus you can use up all available memory in approx. 64 quick steps by: ... I disagree. If the editor uses a very basic implementation, then "Undo to beginning" would probably require the user to perform multiple undo steps, in which case the memory usage would be linear in the number of steps rather than exponential. If the editor supports "Undo to beginning" as a single operation, then it would be reasonable to expect a more sophisticated implementation that does it efficiently -- memory usage can be reduced by sharing the repeated sections of the undo/redo stacks, and it is possible to efficiently skip over undo-redo sequences by recording which states are identical. Exponential memory usage would be indicative of a lazy programmer rather than a fundamental issue with the GRUQ-orithm :)
• Sateeshm 4y ago
  This happens to me frequently both in code editing and designing in Adobe suite, needing some of the redo changes after a series of undos. I usually just cut/copy the the parts i want to keep before doing the undos to get to a previous state and paste them back in. Works pretty well.
• gytdev 4y ago
  the link to "Klonk" is not found. 404