Issues With Undo

See New Implementation of Undo/Redo about the problems with undo/redo when embedded images, embedded windows, or tagged text is involved.

Segfault in TkUndo

The new implementation is eliminating a segfault, try this script:

The tkUndo implementation is crashing. The tkTextUndo implementation (see New Implementation of Undo/Redo) is throwing the correct error instead: nothing to redo.

Polynomial computation time

Since wish8.7 the undo/redo operations need leastwise polynomial computation time, and this makes the undo/redo mechanism more or less useless (for more demanding applications); try example 5 on page Comparison of Old vs. Revised Implementation.

Wrong '-undo' Flag

Something is going wrong with -undo flag, see following example:

The revised version gives this result:

This is of course plausible, the undo stack is disabled (when creating the peer widget), so undoing the insertion is not possible. But wish8.6 is giving this result:

Obviously this result is not plausible, querying the -undo option should give "0" (zero), because the documentation says:

This means that querying this option should answer that the undo mechanism is not active here; note that the content is unchanged after edit undo, even with wish8.6.

Undo is Erroneous

A simple example, showing that even an undo operation without undoing tag associations is erroneous, test this script:

You will see text content "2". Now we add a deletion operation, and an undo of the delete operation:

The undo operation did not properly undo, the result is empty, but the original visible content "2" is expected. With other words, at least the support of elided text requires that edit undo is also undoing tag operations. With revised implementation you will get the expected text content "2".

'Edit modified' Gives Confusing Results

One more example that the old behavior is erroneous, try this script:

The result of this script is:

With old undo behavior the result "not modified" is apparently correct, because the undo cannot revert to the previous state (restoring tag red of newline at 1.end). A different result would be erroneous, look at this example (also see ticket 1536735):

This gives the error message "nothing to undo".

But in fact the result "not modified" is also erroneous, try the next example:

This is the result (left side):

But expected is the result of the right side, because [.t edit mofified] reports "false" (not modified). (Note that the revised version also gives the result on left side because [.t edit undo] works!) This can be verified with the next script, which gives the result of the right side:

Conclusion: [.t delete 1.0 end] is obviously modifying (in this example), because it has an impact on succeeding operations – the operations after delete will give other visual results than without the delete operation.

Summary: with old undo behavior edit modified in general gives incorrect results, in either way. But I did not change this flag for compatibility reasons, instead I've introduced the new flag edit altered (see Additional State 'edit altered'). Fact is that the behavior of edit modified is not useful for computed editor control, because computed editor control requires mathematical (computational) exactness.

Addendum: bug ticket 1536735 (see above) was indeed a bug, because the following script is not modifying: