= 27d567bc2d48d9f40e9ccc20ea370b15)
vi21maobk9vp comments on Tool ideology - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (66)
It looks like an estimation, not a VCS link.
Think of it this way: Vim undo history is a tree which you can walk visiting every branch (not that it's a thing you want to do). Now, writing all this data out has some cost in IO bandwidth - comparable to bandwidth of the keyboard, i.e. kBytes/minute. Vim users don't notice the cost of maintaining the tree in RAM.
Synchronising it at first opportunity is also not hard if you do it in the background and so latency can be tolerated most of the time.
The merges.. you can try to do them mostly on marked commits, and then they can be done just like they are done now.
But implementing all that is a great undertaking, to be sure.
Wait - vim undo is a tree? So I can get back the revisions that I lost by undoing the last 100 operations and then carelessly inserting a character? HOW?
Wow! It is? I had no idea!
From the looks of it this script might be a helpful way to use the feature.
Well, now that you new that it is there, you could just type :help undo-tree. Basically, it is about g+/g-.
And the next chapter of undo.txt tells you about saving undo history.
The limiting case of merge frequency is to do a branch and merge on every keystroke, and create something like Etherpad. This is completely practical.
Ooh, I hadn't thought about it that way - sure, it'd take thousands of those to clog a modern high-speed connection.