On Mon, 2003-12-08 at 13:13, Alan Horkan wrote:
Are there any plans to work on Infinite Undo? Some sort of journalling or suchlike? Should I file an RFE?
Well, in principle there's no reason we couldn't make Undo unlimited, short of actual memory constraints. I certainly don't mind having upped the limit.
The transactions model I added to the SPRepr layer does essentially record a journal of changes during each transaction (a linked list of SPReprActions). It holds references to the actual SPRepr nodes affected, rather than copies, so it is pretty memory-efficient.
You can still have some worst-case scenarios though -- e.g. if many large subtrees have been deleted over the course of the editing session. They'll all unavoidably take up memory in the undo list, somewhat contrary to user expectations.
So, really the choices are:
A. have a (perhaps user-configurable) predetermined undo cutoff (either in undo levels or bytes)
B. allow the user to manually prune the undo list
C. crash when a large undo list OOMs us
(Note that these options are not mutually exclusive...)
Undo accounting in bytes is tricky as many log entries will share data, but certainly doable.
Realistically, are users ever going to backtrack through more than ~300 levels of undo anyway?
Assuming we could actually perform undos that quickly (unlikely on a very complex document...) 300 levels of undo means a full minute of clicking at a sustained rate of 5 clicks/second. Ouch.
Having an undo history window would mitigate that somewhat, but that many undo entries would still be pretty unwieldy. Assuming a decent-sized thumbnail (ignoring the memory cost of that + descriptive labels), 300 entries means scrolling through almost 19 screen-heights on a display 1024 pixels high.
-mental