general undo methods?

[Geoff Canyon]

On Feb 19, 2005, at 10:57 AM, Richard Gaskin wrote:

> Geoff Canyon wrote:
>> I would store a list of transcript statements designed to undo/redo 
>> the things you are doing. So if you move a rectangle to 100,300 I 
>> would get the long id of the rectangle and do something like this:
>> put "set the loc of" && it && "to" && tNewLoc & cr after gRedoString
>> put "set the loc of" && it && "to" && the loc of it & cr before 
>> gUndoString
>> set the loc of it to tNewLoc
>> I did something like this for fields and found it to be remarkably 
>> fast and efficient. The really great aspect is that you can undo/redo 
>> an arbitrary number of steps with one command: do line 1 to 100 of 
>> gUndoString undoes 100 steps, etc.
>
> That's prettyt much where I'm headed now, but there's one aspect 
> that's still problematic:  Rev's built-in undo for text editing 
> operations is something I don't want to replicate.  For a single-level 
> Undo it's easy enough to put a flag in the undo string to tell it to 
> use the built-in undo command rather than any custom routine.  But how 
> would one handle this for multi-level undo?

If you're going to do multi-level undo, I think you have no choice but 
to ignore Rev's built-in undo completely. They can't be stored as far 
as I know, so once something else has been done they're lost.

I have a stack that demonstrates multi-level undo in fields. It was a 
thought experiment and isn't complete:

  -- it doesn't concern itself with _when_ to take an undo step.
  -- it doesn't handle copy/paste and drag/drop efficiently. It should 
work correctly, but the transcript generated is inefficient. For 
drag/drop, the command should be nothing but chunks, since no text has 
changed, but it's not that smart.

I'll email it to you.

regards,

Geoff Canyon
gcanyon at inspiredlogic.com