implemented backup file mechanism

* The backup mechanism is supposed to guard against crashes of SciTECO and
  unexpected program terminations (e.g. power cycling, etc.)
* In a given interval (no matter whether busy or idlying on the prompt)
  SciTECO saves all modified buffers with the filename~ (like most other editors).
  As an optimization files are not backed up if they have been backed up
  previously to avoid pointless and possibly slow file system writes.
* While the backup mechanism exists outside of the usual undo-paradigm -
  backup file creating is not bound to character input and it makes no sense
  to restore the exact state of backup files - there are some interesting
  interactions:
  * When a buffer is dirtyfied or saved that was previously backed up, it must always
    be reset to the DIRTY state on rubout, so backups are eventually recreated.
  * When a buffer is dirtyfied first (was clean), the backup file must be
    removed on rubout as well - we don't expect backup files for clean buffers.
* There is currently no automatic way to restore backup files.
  This could potentially be done by opener.tes and session.tes in the future,
  although you couldn't currently always get meaningful user feedback
  (whether he wants to restore the file).
  Perhaps we should at least log a message when detecting backup files that
  are newer than the file that is being opened.

1 files changed, 5 insertions, 5 deletions

diff --git a/TODO b/TODO
index c56592d..ed3efda 100644
--- a/TODO
+++ b/TODO
@@ -481,11 +481,11 @@ Features:
  * Touch restored save point files - should perhaps be configurable.
    This is important when working with Makefiles, as make looks
    at the modification times of files.
- * There should really be a backup mechanism. It would be relatively
-   easy to implement portably, by using timeout() on Curses.
-   The Gtk version can simply use a glib timer.
-   Backup files should NOT be hidden and the timeout should be
-   configurable (EJ?).
+ * Could we somehow offer to open backup~ files?
+   opener.tes and session.tes operate in batch mode and interactively
+   asking what to do wouldn't always work in the GUI variants.
+   Also, we'd need a command to fetch the modification timestamp
+   as well.
  * Error handling in SciTECO macros: Allow throwing errors with
    e.g. [n]^F<description>^F where n is an error code, defaulting
    to 0 and description is the error string - there could be code-specific