> We know that many of our customers create a lot of untitled documents for quick note-taking, and rely on BBEdit's legendary stability and robust crash recovery to protect their work. We've added a new "Notes" feature in BBEdit 14...
Ooh, guilty as charged. I see an "Untitled text 931". It's a list of hostnames. "Untitled text 107" is a Beef & Broccoli recipe.
This is the main reason BBEdit has been with me for a decade. I have NEVER lost an unsaved document during that whole time. You quit BBEdit or restart or crash macOS but they're always there when you're back in. Insanely robust.
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.
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].
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.
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.
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?
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.
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.
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.
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...
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.
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.
That's what I've been doing with Notepad++ for years and years. It doesn't even prompt you to save when you exit, it just restores your previous open file panes, including ones you didn't save.
Ugh, I do this with Notepad++ too, and I know it's terrible. But it's just so.... automatic. I tell myself that nothing in there is truly critical, but I've also had a few instances of being pretty pleased to be able to "find in all open documents" and recover a bit history of what I was doing, or URLs for some research, or whatever.
I'm utterly unrestrained with it because I don't even use NP++ as a text editor for anything else— my actual projects are in VSCode or just terminal vim instances.
I see a lot of "oh, but this is what a lot of editors do" comments. But BBEdit 14's Notes feature is not "we save untitled files"; it's a little more like the Notes app, or like a more limited version of Ulysses's sheets. It's explicitly about saving documents that you don't bother to give titles to.
Also, a neat trick BBEdit has had since version 13, I think: it can actually recover untitled documents even after you close them and say "no, don't save."
uh, what? that does not sound like a feature to me - I expect that when I close a document without saving it is gone for good. Is there a way to turn that off?
Absolutely. (...checking preferences to make sure I am not lying) Yes! Absolutely. :) You can turn the feature off completely, and if it's enabled, you can set a time limit for "rescued" items before they're completely discarded, e.g., yo could set it so you have a day to rescue them, then they get truly deleted.
I want them to have some paid lite mode, that I could purchase and support them.
Given my use case I feel like $40 is a bit much but I’d gladly pay $20 for a note taking app.
Yeah - it's worth pointing out that BBEdit itself, can partly be used for free, indefinitely. You're allowed access to a subset of features (which is very similar to what TextWrangler offered), without needing to pay.
I think they reached a point where, even if the codebase had originally been forked from BBEdit, it was just plain dangerous to have a second codebase floating around. I think after they had done the same work (bugfixes, feature additions) twice for quite a while, they just decided "yeah, this was a mistake", and pulled the plug.
Ooh, guilty as charged. I see an "Untitled text 931". It's a list of hostnames. "Untitled text 107" is a Beef & Broccoli recipe.