*: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.
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.
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!
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.
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.
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?
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.
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.
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.
In Neovim/Vim this is not hard at all:
There is also a
:latercommand.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.
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!
Vim has branching undo though, so you can go back (forward?) to the original version, just not with
:later.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.
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.
Eclipse had the same feature since I remember - in times very useful indeed.
wow, TIL!
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?
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.
That’s an interesting use of git staging. You can also do this in regular old git with
git add, thengit diffto show unstaged changes.Yeah, I do much the same thing, using
hg commit --secretto create commits that serve as checkpoints. (“secret” means Mercurial won’t push them when I runhg 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.
I also rely on git. Sometimes just
git commit -am asdfjkjland later rebase/squash it all.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.
One way to do something like this in Emacs is to force a backup by adding a prefix argument to
safe-buffer:and a mix of local-undo.
I like the idea of going back to any previous state, certainly seems to be a cleaner approach.
Would be nice if emacs could diff against the undo tree, though I’ve not even looked for such a thing.