UP | HOME
../../

Undo-Redo of an Editor

Table of Contents

1 State

  1. Complete capture ("core" dump?) of the process (program in execution)
  2. Includes state of files …
  3. Includes global and all levels of local variables …
  4. Time stamped, when discussing specs
  5. Compact representation: a major design issue

2 State History

2.1 State History of a variable X

  1. Sequences of values that X ever held from big-bang to current
  2. Each value is time stamped. The time stamp is "abstract", it is not in units/sub-units of seconds. Every time state changes we move from time t to t+1.

2.2 Operations of the Editor

  1. Every Op at t moves St to a "new" state St+1 at t+1
  2. Every Op is completely recorded: Name, and arguments
  3. LOP ::= Last Operation, and we use LOPt [subscript t] when needed

3 Spec of Undo

  1. Suppose the last operation was LOP that mapped state St to St+1.
  2. The relationship between St and St+1 is given by the semantics of LOP; notationally, St+1 := LOP(St).
  3. Undo maps St+1 to St+2, so that St+2 == St.
  4. In the absence of History, Undo is a no-op, mapping St+1 to St+2, so that St+2 == St+1.
  5. Note the growth of History as with other Ops.
  6. Semantics of Undo depends on LOP.
  7. Undo is a higher-order function.

4 Spec of Redo

  1. Suppose St+1 := LOPt(St)
  2. Redo at t+1 maps St+1 to St+2, St+2 := Redo(St+1), so that St+2 is related to St+1 in "a manner similar" to how St+1 and St were. That is, St+2 := LOPt(St+1)
  3. Understand the case: The last operation may be an Undo
  4. Understand the case: The last operation may be a Redo

5 Design of Undo/Redo

  1. Mostly: Representation of State History
  2. Usually: Not undoing/redoing "entire" state
  3. Main design goal: Compact. It is too easy to be exorbitantly large.
  4. Main design goal: Speed. It is too easy to become slow.

5.1 Representation of State

  1. Current state, St: Easy .. trivial
  2. Last state, St-1:
    1. Obvious: a dump of then-current state
    2. Can be heavily space consuming
    3. last-state := current-state plus-minus changes
    4. last-state := LOPt-inverse(current-state), sometimes the LOP-inverse is an easy to compute function

5.2 Representation of State History

  1. Sequence of state values, conceptually
  2. Sequence of LOP-inverse's

6 Undo/Redo Frameworks

  1. Bertrand Meyer's OOP book has a great section on Undo/Redo. (in English)
    1. http://se.inf.ethz.ch/courses/2014b_fall/eprog/lectures/18_undo.pdf in German!
  2. There are now frameworks. A few are listed below.
  3. http://www.infragistics.com/products/wpf/frameworks/undo-redo-framework 2014
  4. http://sydney.edu.au/engineering/it/~aied/vol3/vol3_jansen.pdf 2003
  5. http://repository.cmu.edu/cgi/viewcontent.cgi?article=1307&context=hcii 2015

7 References

  1. Meyer, Bertrand. Object-Oriented Software Construction. New York: Prenticehall, 1988.
  2. http://en.wikipedia.org/wiki/Undo. Not so good. Even so … Recommended Reading.
  3. Edwards, W. Keith, Takeo Igarashi, Anthony LaMarca, and Elizabeth D. Mynatt. "A Temporal Model for Multi-Level Undo and Redo", Proceedings of the 13th annual ACM symposium on User Interface Software and Technology (UIST), 2000. https://research.cc.gatech.edu/ecl/sites/edu.ecl/files/C.29-Edwards-UIST-2000.pdf Highly Recommended Reading.
  4. James O'Brien, and Marc Shapiro. "Undo for anyone, anywhere, anytime." In Proceedings of the 11th workshop on ACM SIGOPS European workshop, p. 31. ACM, 2004. Recommended Reading.
  5. Merlino, Hernán, Oscar Dieste, Patricia Pesado, and Ramón García-Martínez. "Software as a Service: Undo." In SEKE, pp. 328-332. 2012. http://www.unla.edu.ar/sistemas/gisi/GISI/papers/SEKE-Merlino.pdf Recommended Reading.
  6. Alessandro Warth, Yoshiki Ohshima, Ted Kaehler, and Alan Kay, "Worlds: Controlling the Scope of Side Effects", European Conference on Object-Oriented Programming, 2011. Recommended Reading.

8 End

Copyright © 2018 • www.wright.edu/~pmateti 2018-10-15