If you've ever been saved by an Emacs backup file, you
probably want more of them, not less of them. It is annoying
that they go in the same directory as the file you're editing,
but that is easy to change. You can make all backup files go
into a directory by putting something like the following in your
.emacs.
(setq backup-directory-alist `(("." . "~/.saves")))
There are a number of arcane details associated with how Emacs
might create your backup files. Should it rename the original
and write out the edited buffer? What if the original is linked?
In general, the safest but slowest bet is to always make backups
by copying.
(setq backup-by-copying t)
If that's too slow for some reason you might also have a look at
backup-by-copying-when-linked.
Since your backups are all in their own place now, you might want
more of them, rather than less of them. Have a look at the Emacs
documentation for these variables (with C-h v).
(setq delete-old-versions t
kept-new-versions 6
kept-old-versions 2
version-control t)
Finally, if you absolutely must have no backup files:
(setq make-backup-files nil)
It makes me sick to think of it though.
The immutable objects would hold the entire state of the system, so in this case you'd have object A that contains the original inbox, and then object B that contains the inbox with ten e-mails deleted, and (in effect) a pointer back from B to A indicating that, if you do one "undo", then you stop using B as the state of the system and start using A instead.
However, Gmail inboxes are far too large to use this technique. You'd use it on documents that can actually be stored in a fairly small amount of memory, so that you can keep many of them around for multi-level undo.
If you want to keep ten levels of undo, you can potentially save memory by only keeping two immutable objects - one that is current, and one that is from ten "undos" ago - and a list of Commands that were applied between them.
To do an "undo", you re-execute all but the last Command object, use that as the new current object, and erase the last Command (or save it as a "Redo" object). Every time you do a new action, you update the current object, add the associated Command to the list, and then (if the list is more than ten Commands long) you execute the first Command on the object from the start of the undo list and throw away the first Command on the list.
You can do various other checkpointing systems as well, involving a variable number of complete representations of the system as well as a variable number of Commands between them. But it gets further and further from the original idea that you cited and becomes more and more like a typical mutable system. It does, however, avoid the problem of making Commands consistently reversible; you need only ever apply Commands to an object forward and not reverse.
SVN and other version control systems are effectively a disk- or network-based form of undo-and-redo.
Best Solution
Short version: by undoing the undo. If you undo, and then do a non-editing command such as C-f, then the next undo will undo the undo, resulting in a redo.
Longer version:
You can think of undo as operating on a stack of operations. If you perform some command (even a navigation command such as C-f) after a sequence of undo operations, all the undos are pushed on to the operation stack. So the next undo undoes the last command. Suppose you do have an operation sequence that looks like this:
Now, you undo. It undoes the last action, resulting in the following list:
If you do something other than undo at this point - say, C-f, the operation stack looks like this:
Now, when you undo, the first thing that is undone is the undo. Resulting in your original stack (and document state):
If you do a modifying command to break the undo sequence, that command is added after the undo and is thus the first thing to be undone afterwards. Suppose you backspaced over "bar" instead of hitting C-f. Then you would have had
This adding/re-adding happens ad infinitum. It takes a little getting used to, but it really does give Emacs a highly flexible and powerful undo/redo mechanism.