Vim (cross-platform) supports ability to restore from the "swap" file (by default, AFAIK, but that may very well be a special configuration decision by my distro).

If your system crashes or you lose power while editing foo.src, it will leave the swap file behind, which is eagerly written to disk while editing and only removed when the process shuts down gracefully. When you bring your system back up and try to edit foo.src again, you'll get a message "Swap file ".foo.src.swp" already exists!" and prompt you for whether you'd like to recover it or not. Any unsaved changes you made will be reconstructed from swap, rendering the file in the same state it was before.

Vim also supports a closely related concept "sessions", which you can force with ":mks" and restore with the "-S" flag. This will re-open whatever files you had open at the time, in the same layout, and more.

What would be interesting to see are "super swap files" that are passively created (like ordinary swap files, requiring no intervention) but do everything that session files do and more, like preserving movements, markers, undo history try, etc. -- essentially getting you back to exactly what you had at the time of the interruption.

What is the performance cost of this sort of thing? I suppose it depends on how often it autosaves, but if it's too infrequent you end up loosing work anyway, and you could imagine it being a problem for files above a certain size.

What's the performance like? Real fuckin' fast. Ever used Vim? I don't and never have used hardware that would be considered especially beefy.

Probably 25 years ago now, I've trained myself to habitually use "vim -n" for very large files for which recovery isn't required.

The swap file stores edits rather than the whole file. I guess this could be laggy if you were doing global substitutions on a massive log file, say, but I've never had an issue. Vim was written for much slower computers.

IMO every program must work like this. I hate so much those "do you want to save this file" when I close a program. Don't ask me, just save it somewhere and restore when I open the program next time. It's trivial to implement and much easier to use.

> It's trivial to implement and much easier to use.

...unless you opened the document from a network share or removable media. Or serialization takes a long time. Or the storage device is slow. Or you don't have write permission in the file's original location and have to pull a potentially large file from somewhere to persist changes to some local position. Or the local storage device is full.

A "always save" mechanism would be best on a system that supported copy-on-write, network-aware links, and automatic file versioning to make writes super cheap. On actual real world systems that currently exist these mechanisms don't really exist or aren't universal so "always save" is fraught with difficult to handle edge cases.

You don't have to write in the same directory as the original file (and you definitely don't want to overwrite the original file). Original vi (and nvi) keeps the working copy below /var/tmp. If you can't write there, you have bigger problems.

(just be consistent from which host you modify a file from ;-}

Writing to /tmp is great if your file is loaded entirely in memory. Not all programs do that for a variety of reasons. Like I said, it's the tons of edge cases that make "constantly save" problematic and far from a trivial feature.

/tmp often is a RAM based file system. Not the best destination for data intended to be permanently saved. (n)vi is primitive enough to insist in copying the whole file (usually not a problem with files meant to be edited interactively), but nothing stops a more sophisticated program to store only changes (transactions) and consolidate on request. Most software, certainly all interactively used, ought to be "crash-only" software [1].

[1] https://www.usenix.org/conference/hotos-ix/crash-only-softwa...

There have been a lot of scenarios where blowing away everything since the last save and reverting to known-good via the Open command has saved my ass.

The solution I think works best is to flash/blink the Save button when a file has changed. And ask them to save when they leave. Then, the user is more easily reminded to save when they feel it is most appropriate to do so, but is not compelled into saving and can revert to a previous version if they like.

It was even better working on a system that versioned files automatically so programs didn't need to re-implement these sorts of wheels continually.

Dave Cutler was right.

Only a minority of programs need that functionality. Databases and everything which implements transactions or version control itself, certainly don't. Neither all the temporary files, e.g. a compiler creates. If version control of your configuration files is external to the host (e.g. if some configuration management system like puppy, chef, etc. is used) then it's get in the way as well.

Dave Cutler was wearing his marketing hat when he claimed that such functionality belongs in the file system code. It would be nice, if it were in a library all interested applications could easily link to though.

I essentially have versions for all my files because of Apple’s “Time Machine” backup system. There’s the external drive at my desk and there’s also the cache of recent changes it maintains in free space on the local drive.

Both of these have saved my ass in the past. I don’t care if it’s actually part of the file system, but it sure as hell belongs somewhere in the OS IMHO.

> Databases and everything which implements transactions or version control itself, certainly don't.

Why should programs implement these themselves? It should be part of the OS.

I don't think you can get Oracle, IBM, etc. to agree on how a database ought to be implemented. It clearly depends on the use case as well. More fundamentally one can argue, that what can be implemented in userspace ought to be implemented in userspace (for security and maintenance reasons alone), rather than the kernel. And what good does a db do in a compute node?

Sublime Text has always performed similarly for me

Yep, ST’s unsaved default workspace is completely reliable for me—it’s survived power outages on my desktop (while I was actively typing) without a hitch.

This Sublime feature has worked for me except for a single time... During one of the interim, 3.x upgrades I lost all of the open but not saved notes files.

I had that issue when upgrading from 3.x->4 -- I was so cocky from years of ST's insane consistency that it honestly didn't even occur to me that my unsaved documents might be lost.

I wasn't even mad; just a little surprised

I didn't have this issue when upgrading to 4, just on an interim 3.x update. Maybe the OS made a difference. I had that issue on a Mac.

This is the reason I haven't upgraded to Sublime 4 yet.

Emacs. Emacs will autosave every 300 keystrokes or 30 seconds of idle time. You can also configure it because well its Emacs. Has saved my butt on numerous occasions.

It will not reload your session by default but you can do that if you want.

+1 for Emacs autosave. Note that an autosave file is not the original file you were working on but a copy saved at the interval you specify. The original file is left untouched until you explicitly save it.

In case Emacs aborts for some reason, at restart Emacs will alert you that the newer copy exists and ask if you want to use the copy instead, which you usually (but not always) do.

If you want Emacs to automatically save the original file after a configurable interval, use auto-save-visited-mode.

Jetbrain's products have the concept of scratch files, of which I've made thousands over the years.

> Is there anything like it on Linux?

VSCode. I use it on Mac and Linux and make heavy use of this feature.

Vscode was one of those “Microsoft made an editor on electron? Why would anyone use that” to “WSL2 and vscode is way better than mac” debates I have now. Am I the baddie? Btw I would just use Linux if my friggin corporate overloads supported it. I could BYOD but all my devices have some sort of pirated movie or a doom2 wad from the internet that I don’t feel like talking to HR about.

Visual Studio Code has yet to lose workspaces, untitled documents or unsaved changes for me. What is more likely to happen for me is accidentally running Git commands while I had buffers in VSCode with unsaved changes.

I ran into this issue [0] when updating VSCode which caused it to delete the contents of my unsaved/untitled document.

[0]https://github.com/Microsoft/vscode/issues/69972

OK. So relying on unsaved buffers long-term might still be less safe than in BBEdit, assuming Microsoft hasn’t made improvements that prevent this sort of scenario from happening again.

However, it definitely wasn’t out of sheer negligence, as they do have tests that try to ensure unsaved data will make it from the last stable version to the current version at all times. Without doing any serious research, all I can say is that it is unfortunate, but if you don’t keep unsaved buffers and changes for long periods of time it is at least fairly safe...

https://github.com/microsoft/vscode/blob/main/test/smoke/src...

I think this is the sort of thing where trust is lost after just once, never to be regained. Sort of like if someone lies to you, you can never trust them again, because they've done it once.

I think think because software is so new, and the choices are still so slim, many are much more lenient than they would be with a human.

However, as it matures, and there are more choices, we can regain the freedom to exclude any software from our lives after it misbehaves just once, and still have plenty of choices.

Personally, I've given up on Mac, and before that iOS, and before that Windows, and I'm so much happier, because I have invested that time into choices which do not let me down.

I've done the same with dishonest services, too. No more LinkedIn, their emails forever trashbinned.

But like people, the circumstances matter. VSCode dropping the ball once has to be weighed against why it happened, what they were doing to prevent it from happening, etc. If it happened more, you’d lose trust in that feature, but it’s hard to leave something over a single feature that’s buggy. I can’t think of another text editor I’d rather be using.

For me, I don’t rely on this feature because I normally save anything that I want to keep for longer than a day. My PoV is that anything that isn’t backed up is already lost, so if it really matters, I need more than just hoping my software and hardware won’t fail. Dropping unreliable software is still always an improvement, but if I dropped every piece of software that ever failed me, I would have no software.

Sublime Text.

vim: https://github.com/chrisbra/vim-autosave

Any sufficiently large thread about text editors contains a pitch for an ad hoc, bug-ridden, unnecessary plugin that's overkill for achieving some effect which is already possible just using a build of Vim mainline.

:help swap-file

Isn’t that a native feature in MacOS? I never “lost saves” since years.