1. 36

  2. 21

    In Neovim/Vim this is not hard at all:

    							*:ea* *:earlier*
    :earlier {count}	Go to older text state {count} times.
    :earlier {N}s		Go to older text state about {N} seconds before.
    :earlier {N}m		Go to older text state about {N} minutes before.
    :earlier {N}h		Go to older text state about {N} hours before.
    :earlier {N}d		Go to older text state about {N} days before.
    :earlier {N}f		Go to older text state {N} file writes before.
    			When changes were made since the last write
    			":earlier 1f" will revert the text to the state when
    			it was written.  Otherwise it will go to the write
    			before that.
    			When at the state of the first file write, or when
    			the file was not written, ":earlier 1f" will go to
    			before the first change.

    There is also a :later command.

    1. 9

      Yes, Vim’s :earlier/:later commands are nice; and so is Vim’s undo tree (especially with a graphical interface). But in both cases, you still have to flip back and forth between the historical version and your working code. Splitting the buffer doesn’t help, because :earlier affects all splits where that file (buffer) is open.

      The author’s Yestercode is a further improvement: it lets you pull up earlier states of your file next to the window where you’re editing it, so looking something up does not break the edit flow.

      1. 2

        This basically undo’s, so you won’t be able to use forward again when (accidentally) changing history. But yes, it is a nice feature, I use it as well!

        1. 4

          Vim has branching undo though, so you can go back (forward?) to the original version, just not with :later.

      2. 11

        One of my most used non-obvious features of IntelliJ-based IDEs is Local History; basically a permanent undo history of a file, with a diff viewer for each change. It’s not always the most convenient (or reliable), and I often still end up doing the undo/redo thing mentioned in the article, but it comes in useful often enough when I need to look at something from 5 minutes (or days) ago that I didn’t anticipate needing to look back on.

        1. 1

          wow, TIL!

          1. 1

            Eclipse had the same feature since I remember - in times very useful indeed.

            1. 1

              Yes! I’m amazed this is not in Visual Studio. IntelliJ just saves your changes all the time and you can go back 5 minutes. I don’t need it often but it’s a life saver.

            2. 5

              Wow, this is pretty interesting. I don’t often find myself needing to view some intermediate stage of the code mid-change, and I hardly ever use undo. So there’s a large number of people who have a totally different experience of programming to me!

              But I do heavily use the git staging area, staging a file, method, block, or even individual line as soon as I feel I’ve got it right. I use magit in emacs, making staging or committing things line-by-line almost trivially easy. So I work in very small chunks, perhaps that’s why?

              1. 4

                I’ve been able to solve most of this pain with regular old git and SourceTree’s “split view staging” where the staged/unstaged parts of the same file can be inspected separately. Changes that I’m still working on are unstaged, and when I think I’ve hit a minor milestone that doesn’t warrant a commit I drag them up to the “staged” area. This sets a checkpoint and if I make a mess, I can view only my subsequent changes in the “unstaged” area and revert them in isolation.

                1. 3

                  That’s an interesting use of git staging. You can also do this in regular old git with git add, then git diff to show unstaged changes.

                  1. 3

                    Yeah, I do much the same thing, using hg commit --secret to create commits that serve as checkpoints. (“secret” means Mercurial won’t push them when I run hg push.)

                    When I want to compare my current work in progress to some entirely other version of the file (also common), I create a copy in the working directory using hg cat -r 123 myfile.txt > 123.myfile.txt. Als always, Git has an (a) clumsier command that (b) does the same thing (emphasis on both parts): git show 1a2b3c:./myfile.txt > 1a2b3c.myfile.txt. (Using a hash here because Git doesn’t have local revision numbers.)

                    Still, all these workarounds depend us on remembering to stage/commit or commit our edits at logical points. It’s a pity I don’t use Atom; but I’m really grateful to the author for their realisation, and I hope the tool will spread to other editors.

                    1. 2

                      I also rely on git. Sometimes just git commit -am asdfjkjl and later rebase/squash it all.

                    2. 4

                      yeah, I’m one of the programmers that does this. and I do it for everything. stored procedures c# javascript, everything. why? because my first and second attempts at solving a problem usually suck. Also lots of my code is public. I don’t want to show anyone my crappy intermediate code edits. I know I could use git amend, but I don’t like that either. Also, sometimes that intermediate code I write doesn’t compile. Sometimes I just want to see what it looks like in the IDE. Usually I solve this by copying the file into notepad++ and then playing around with the code in my IDE. If there was a plugin for vscode that would take a snapshot of a file and save it in another folder with a timestamp, I’d really appreciate it. A slider would be nice, but I’d be happy with that.

                      1. 2

                        One way to do something like this in Emacs is to force a backup by adding a prefix argument to safe-buffer:

                        By default, makes the previous version into a backup file if previously requested or if this is the first save.

                        Prefixed with one C-u, marks this version to become a backup when the next save is done.

                        Prefixed with two C-u’s, makes the previous version into a backup file.

                        Prefixed with three C-u’s, marks this version to become a backup when the next save is done, and makes the previous version into a backup file.

                        and a mix of local-undo.

                        I like the idea of going back to any previous state, certainly seems to be a cleaner approach.

                        1. 1

                          Would be nice if emacs could diff against the undo tree, though I’ve not even looked for such a thing.