Disable Auto-Save and add a Save Revision option instead of using Save As to save as a new project.
Having auto-save enabled all the time is dangerous because temporary source changes designed for testing can become accidentally permanent. Also, using Save As to try to keep different revisions or backups is not very graceful because it save it as an entirely new project, and not just a revision of the same project.
I've almost lost an entire project when my computer lost power. The file was still there, and was the right size, but it was entirely blank. I suspect this is because Inform keeps the file permanently open and only writes to it after closing the program or during an auto-save.
Can we at least have an auto-backup feature where one former revision is stored as a .bak file? This would be some kind of "insurance" cache against faulty saves, power loss, or losing your undo history to fix unintended mistakes.
Andrew Plotkin commented
This is several different topics.
The Inform compilers work on files, not on the IDE's live state. So I expect that auto-save will remain the order of the day -- if the IDEs don't go all the way to "always saved, no explicit command for saving." Which they might.
Conclusion: if you type it, expect it to be saved.
The IDE treats a project as a unit, always saved or duplicated as a whole. (On the Mac, the project appears to the user as a solid package, not a folder.) Again, this is not going to change.
The IDEs *don't* keep the source file open all the time. I know the Mac IDE uses a standard "save new file, move to final destination" idiom; I suspect the Windows IDE does too. There's no reason to expect the source file to be corrupted by any kind of crash. (If you look at project/Source/source.ni while the IDE is open, you'll see it's fine.)
Now, I have seen a report of a user losing their source file. This is worrying, but it's been so rare that we haven't gotten a handle on any possible cause.
Keeping the previous revision as a .BAK file is possible. But I don't think it would add much. Even in the rare corruption case, most users won't know to look for it. They're more likely to re-launch the app, and would almost certainly wind up saving the bad file over the .BAK at least once.