Auto save about 6502bench HOT 3 CLOSED

There are a couple of approaches:

1. Implicitly hit Ctrl+S every N minutes.
2. Frequently save to a "recovery" file. This leaves the original project unchanged until Ctrl+S is hit. This requires a bit more logic, as you need to test for the presence of a recovery file, and present UI during file open if found (to allow the user to pick which one to open). It also means you get temporary files sitting around while you work (e.g. the VIM ".swp" files).

#⁠1 is simpler, but #⁠2 avoids the situation where you make a bunch of speculative changes that you want to throw away, and discover that you can't because it auto-saved.

Regardless of approach, we should pop open the Save As dialog as soon as the project is opened. If the user cancels out of the dialog, we open the new project with auto-save disabled.

The simple implementation is:

• Add a timer that resets when the file is saved. If this is a new project that has never been saved, the timer won't start, because we don't know where to save it.
• When the timer expires, do a full save.
• Make it configurable: off, 1 minute, 5 minutes.

The more complicated approach is:

• Add a timer that resets when a change is made. After N seconds without a change, save to the recovery file. (On a modern system with file caching the file I/O shouldn't be noticeable, but I'd like to do this during bouts of idleness.)
• Make it configurable: off, 10 seconds, 30 seconds.
• When the project is closed, delete the recovery file.
• When a project is opened, look for a recovery file.
  • If not found, create one, and immediately save the project to it. (This could also be deferred until the first time a change is made.)
  • If found, the application must have exited abnormally. Display the file modification times, and ask the user to pick.

This gets slightly weird in one aspect: if a recovery file is found when a project is opened, the file will be overwritten after the user makes their choice, because we need a recovery file for the new session. We need to be clear that, if the user wants to keep both versions, they need to cancel the open and rename the recovery file. We could also disable auto-save for that session, but that means the user will need to manually remove the recovery file. (Better: mark the project as "dirty", and disable auto-save until the first manual save. Leave both files intact until then.)

The presence of the recovery file would also prevent the project from being opened read-write in two separate instances. That's something we probably want to be doing anyway. The application should keep the recovery file open, so the second instance can tell the difference between active and failed sessions. The recovery file name is always the name of the project file with "_rec" added (so it's a ".dis65_rec" file). If the user does a Save As, we should discard the current recovery file, and create a new one with the new name.

The timer should also be reset when the user does a manual save. There is some value in having the file saves be spaced apart in time, in case a system crash causes file corruption. (Not as much of a concern with modern journaled filesystems.)

from 6502bench.

#2 seems like a lot of work.

#1 would get my vote cause if I saved the project when I initially created it and it save every so often I would be in a better state.

Maybe when the project is initially created do a save right there and proceed with #1.

from 6502bench.

Two changes are in https://github.com/fadden/6502bench/releases/tag/v1.9.0-alpha2 :

1. After creating a new project, a "save as" operation is performed. If you cancel out of the dialog, you get the old behavior. (You also get a weird error message that I just now spotted. Harmless, fixed in next release.)
2. Approach #⁠2 has been implemented, more or less as planned. It was more work, but I think it'll work better.

from 6502bench.