Re: Programming challenge: Undo

[Harry Binswanger hb@xxxxxxxx]

Robert,

I *began* by addressing the issues you list here:
> This whole question of designing an UNDO command requires a
> great deal of clear definition, before anyone could begin to
> craft a solution. What actions need to be UnDone? What
> constitutes an action? A single keystroke? A formatting
> command? Use of a frame in U2? Use of a native command (like
> GoText func GT)? What???? All of the above? And Undo to how
> many levels? Would each user select the actions that merit an
> Undo, by inserting a function in their KBD file (similar to the
> way STack works)?
>
> What's the TOTAL CONCEPT? Don't say "like Microsoft Word's
> UnDo" -- you need to spell it out.

I think I did:

≪Conceptually, I would think the melody would go a little like this . . .
Maintain "trailing versions" of the current file, in a separate window (or
separate launch of another iteration of Xy). I wouldn't store every
alphanumeric keystroke (since we're only going to have a few levels of
undo), but these prior-version files are updated maybe after every 20th
alphanumeric keystroke and before every command or function is executed.

The thing that make this feasible is the speed of modern hardware.
If this could be done by launching a separate Xy window and passing through
the changes, there could be nine trailing versions--i.e., 9 levels of undo.
There would be a need to format or display the trailing versions of the
file in some way that didn't confuse the user as to which--current or
trailing--he was looking at.
Actually, here's a radical suggestion: keep the trailing versions in
Notepad. That way, no one will be confused. Maybe U2's copy-and-paste to
Windows could be used here. ≫



Harry Binswanger
hb@xxxxxxxx