Re: undo

[jacobs@arthur.inria.fr (Ian Jacobs)]

In article <47110@sophia.inria.fr>, Vincent.Prunet@sophia.inria.fr (Vincent
Prunet) writes:
|> 
|> => Some tools may be updated at every modification and some tools may be
|> updated
|> => only once in a while.  For this reason, the variable may have to store
|> => several different modification paths.  In this respect, having a function
|> => ({variable}:undo variable) would not make much sense.
|> 
|> Guy Durrieu, Valerie, and I were thinking of a different function
|> which would take a path as second argument. Maybe we should call
|> this function {variable}:undo-modif or {variable}:apply-modif.
|> 
|> One can see in the documentation that {variable} functions enable
|> to change, insert or delete a subtree, and also to get
|> modifications (structured diffs) between 2 states of the tree. I
|> regret that there does not exist a function which would apply such
|> a modification to a variable exactly as if atomic modifications
|> were applied in sequence.

Although the function {variable}:undo does make sense in a system
with only one undo possible at a time (the current system, for example),
I am in favor of the more general modification path interface which 
consists of only two modification path functions:
                                                      -1
           apply : tree -> modif -> (tree' , modif ) 
           
           accumulate : modif1 -> modif2 -> modif3

In this world, undo consists of applying a previously applied and inverted
modification path. This may be easily extended to redo as well. These functions
are easily encapsulated in a variable interface. Of course, the variable 
must be responsible for memorizing the history of modifications.
The accumulate operation is performed by the variable which constructs
a tool's modification history. Each undo "pop" the most recent modification
from the variable's history and applies the inverse of the modification
to every tool's history, essentially subtracting it from the history.

N.B. The treemanager implements an unlimited modification history
     with modifications stored on disk and reread when necessary.
     I urge anybody at sophia to contact me before reworking the variable
     interface or implementation.

|> Shouldn't we integrate this function in the code and documentation?

For the moment, it should be written and documented, but I hope
the treemanager will replace the variable in Centaur 1.4

Ian





     
Ian