[BryantD]

I think maybe one other lesson, although I certainly agree with yours, and with the other commenters who talk about the unreliability of this particular method? This feels like an argument for using an editor that autosaves history. "Disk is cheap," as they say -- so what if your undo buffer for any given file goes back seven days, or a month? With a good interface to browse through the history?

I'm sure there's an emacs module for this.

[compiler-guy]

Most of Google's internal development happens on a filesystem that saves absolutely everything in perpetuity. If you save it, the snapshot lives on forever--deleting stuff requires filing a ticket with justification. It is amazingly useful and has saved me many times. Version control is separate, but built on it.

When I eventually move on, I will likely find or implement something similar. It is just so useful.

[julian_t]

I used to rely on this on the old DEC systems, when editing and saving foo.dat;3 gave you foo.dat;4. It didn't save everything forever - and you could PURGE older versions - but it saved enough to get me out of trouble many times.

[vidarh]

My editor syncs the total editing state to disk every few minutes, across all open instances.

I eventually added support for killing buffers, but I rarely do (only if there's stuff I need to purge for e.g. liability reasons). After a few years use, I now have 5726 buffers open (just checked).

I guess I should garbage collect this at some point and/or at least migrate it from the structure that gets loaded on every startup (it's client-server, so this only happens on reboot, pretty much), but my RAM has grown many times faster than my open buffers.

[mosdl]

Jetbrain's local history has saved my bacon several times. Its a good use of all that unused disc space.