To be honest, this was the biggest thing I missed when I started using Windows again 5 years ago. On macOS, basically everything support ‘sudden termination’. This is a feature that was added to XNU for iOS, where there’s no swapping and so memory exhaustion will kill processes. A process periodically marks itself as having committed all user data to persistent storage and being eligible to kill. The kernel will then effectively kill -9 the process when it needs memory (there are some fun things on macOS, where the window server keeps a copy of the window contents, so it can show the application in parallel with restarting it). As a side effect of requiring the kernel to be able to kill the process without data loss in all applications, you can often kill applications without data loss. Cocoa APIs make atomic saves a single Boolean flag change in the writeToFile:atomically: methods, so unless there’s a serious problem with the disk or filesystem, you don’t lose data.
This is truly one of the biggest industry changes in the last couple of decades. Atomic saves (never again come back to half a file), auto-save, time-based undo (that is, being able to go states A → B → A → C → B), and opening the last file when starting an application. These are the real steps forward.
I really don’t like the model where editing immediately modifies the file.
I have three separate backups (to two types of media), but not because of hardware or power failure, but because the biggest hazard to my data is myself. I accidentally trash/edit/delete files far more often than my disk gets corrupted or my power is lost. Because of that, I really appreciate the mental step of “save the file once I’m happy with what I’ve done.”
When I think about opening a disk file in an editor, I imagine the editor copying the file into memory so I can make changes to the memory image. When I’m satisfied of my changes I can save them back into the disk file, replacing the contents. If I try to close the window without saving, I’m prompted “do you want to save?”. If I’m surprised by a “do you want to save?” prompt, then I somehow modified the editor’s copy without realizing it, and can figure out what to do. It all works.
On the other hand, if the OS/editor treats “editing” as “directly changing the file”, then I’ve lost that protection. Sure, it’s nice to preserve data in the case of power loss or a crash, but that can be done in other ways without breaking the model I find so helpful.
Agreed! To me, my mental model is that save really means commit. I really want to be able to discard and roll back my changes if I don’t like where they are going. (I hate it when apps don’t give me a revert option.)
The auto-saves that really drive me nuts, though, are the ones where it’s to a shared resource on a server or a cloud drive. Then I get paranoid that a stray keypress might have accidentally introduced a typo or deleted a chunk of text in a shared document that others will be viewing.
I have the opposite problem, auto-save is not enough for me if it’s purely time based and I hate remembering to explicitly save. I have a kakoune hook that writes all buffers onto disk when window loses focus. Thus I don’t have to worry about having files in inconsistent state when I open gitui, run git, run formatter etc. And for the typo/revert paranoia (that I also have) I just use git, I don’t really edit files without version control. And for config files I use sudoedit.
For Etoile, we aimed for both. We gave you unlimited persistent undo, but the ‘save’ analogues were ‘name’ and ‘export’. You could name a specific revision of the document by attaching metadata to it that would let you find it later. Exporting was intended for interoperability and gave a flattened version of the file in an interchange format (e.g. PNG, HTML, PDF, ODF, whatever).
My first experience with auto-save was with Google Docs. “Just close the tab” took some getting used to, but it makes sense in a WYSIWYG context of a piece of paper. Like paper, you just pick up where you left off.
I like this too. For some reason though, I always distrust it. I guess I’m so used to pressing CTRL-s.
Word 6.0 for Windows 3.1 had a nice autosave feature. You could set it to autosave every X minutes. It was kind of annoying when that was removed and replaced with a save autorecover feature. I didn’t want to search for an autorecovery file that might or might not be there.
To be honest, this was the biggest thing I missed when I started using Windows again 5 years ago. On macOS, basically everything support ‘sudden termination’. This is a feature that was added to XNU for iOS, where there’s no swapping and so memory exhaustion will kill processes. A process periodically marks itself as having committed all user data to persistent storage and being eligible to kill. The kernel will then effectively kill -9 the process when it needs memory (there are some fun things on macOS, where the window server keeps a copy of the window contents, so it can show the application in parallel with restarting it). As a side effect of requiring the kernel to be able to kill the process without data loss in all applications, you can often kill applications without data loss. Cocoa APIs make atomic saves a single Boolean flag change in the writeToFile:atomically: methods, so unless there’s a serious problem with the disk or filesystem, you don’t lose data.
This is truly one of the biggest industry changes in the last couple of decades. Atomic saves (never again come back to half a file), auto-save, time-based undo (that is, being able to go states A → B → A → C → B), and opening the last file when starting an application. These are the real steps forward.
I really don’t like the model where editing immediately modifies the file.
I have three separate backups (to two types of media), but not because of hardware or power failure, but because the biggest hazard to my data is myself. I accidentally trash/edit/delete files far more often than my disk gets corrupted or my power is lost. Because of that, I really appreciate the mental step of “save the file once I’m happy with what I’ve done.”
When I think about opening a disk file in an editor, I imagine the editor copying the file into memory so I can make changes to the memory image. When I’m satisfied of my changes I can save them back into the disk file, replacing the contents. If I try to close the window without saving, I’m prompted “do you want to save?”. If I’m surprised by a “do you want to save?” prompt, then I somehow modified the editor’s copy without realizing it, and can figure out what to do. It all works.
On the other hand, if the OS/editor treats “editing” as “directly changing the file”, then I’ve lost that protection. Sure, it’s nice to preserve data in the case of power loss or a crash, but that can be done in other ways without breaking the model I find so helpful.
Agreed! To me, my mental model is that save really means commit. I really want to be able to discard and roll back my changes if I don’t like where they are going. (I hate it when apps don’t give me a revert option.)
The auto-saves that really drive me nuts, though, are the ones where it’s to a shared resource on a server or a cloud drive. Then I get paranoid that a stray keypress might have accidentally introduced a typo or deleted a chunk of text in a shared document that others will be viewing.
I have the opposite problem, auto-save is not enough for me if it’s purely time based and I hate remembering to explicitly save. I have a kakoune hook that writes all buffers onto disk when window loses focus. Thus I don’t have to worry about having files in inconsistent state when I open gitui, run git, run formatter etc. And for the typo/revert paranoia (that I also have) I just use git, I don’t really edit files without version control. And for config files I use sudoedit.
For Etoile, we aimed for both. We gave you unlimited persistent undo, but the ‘save’ analogues were ‘name’ and ‘export’. You could name a specific revision of the document by attaching metadata to it that would let you find it later. Exporting was intended for interoperability and gave a flattened version of the file in an interchange format (e.g. PNG, HTML, PDF, ODF, whatever).
My first experience with auto-save was with Google Docs. “Just close the tab” took some getting used to, but it makes sense in a WYSIWYG context of a piece of paper. Like paper, you just pick up where you left off.
I like this too. For some reason though, I always distrust it. I guess I’m so used to pressing CTRL-s.
Word 6.0 for Windows 3.1 had a nice autosave feature. You could set it to autosave every X minutes. It was kind of annoying when that was removed and replaced with a save autorecover feature. I didn’t want to search for an autorecovery file that might or might not be there.