Multi-Window Undo Validation

[rjkroege]

Undo actions can affect multiple windows in Edwood. This needs better testing to be sure that the file.Buffer work (#97) doesn't regress. Completing this issue entails fixing the noted issues and creating tests that show correct behaviour.

Context

• Create at least 2 Window objects a and b with underlying Text etc.
• Each Window is backed by an on disk file (needed for some tests.)

Cases

Simple multi-undo

1. Mutate a, b simultaneously (via Edit command) on a
2. Undo correctly undoes both mutations from either a, b
3. Redo correctly redoes both mutations from either a, b

Branched a

1. Mutate a, b simultaneously
2. Mutate a
3. Undo a only undoes mutation 2

Branched b

1. Mutate a, b simultaneously
2. Mutate a
3. Undo b only undoes the first (simultaneous) mutation.

Branched and rejoined (and rebranched a)

1. Mutate a, b simultaneously
2. Mutate a
3. Undo b (undoes 1 in b)
4. Undo a (undoes 2)
5. Undo b does nothing
6. Undo a (undoes 1)
7. Redo on a,b applies 1 to both
8. Redo on a applies 2 to a

File Name Change with Mutli

1. Change a's name to c
2. Mutate c, b simultaneously (via Edit command) on c
3. Undo or c,b removes 2 from ca and b, a remains having a different file
4. Undo returns c to a
5. Redo makes a back to c
6. Undo makes c back into a

The 5 to 6 transition is wrong: it takes two Undo actions. This is a persistent fault. Hypothesis: seq is being incremented one additional time somewhere.

File Name Change

1. Change a's name to c (note that currently the cursor position is wrong in the title bar after the Undo action.) (I think that this is a regression that I caused when I removed mod.)
2. Mutate c
3. Put c
4. Undo 2 (c becomes puttable)
5. Undo 1 (c's name becomes a). a is puttable. Arguably, a should not now be puttable because it's unmodified compared to the disk version. Perhaps track the putseq in the undo record when the file name is changed? This might overlay with #372.

[rjkroege]

Fixed #394.