The current transaction can be continued through 'ChangeCompleted' operations via use of the `continueCurrentTransaction` flag. But calling `ChangeCompleted` was still clearing the `customChangeInProgress` flag, which made the ChangeHistory forget that it was in the middle of a custom change. This caused issues if the selection was automatically changed (such as clicking in the text tool) after a custom no-data change (such as from changing the anchor name in the anchor-text)
Previously, it was notifying change, but before an actual change was made: just when the ViewPort was requesting a token so that it can change. At that point, there's no actual change yet, so CanExecuteChange was still returning false.
* Don't allow inserting a custom change during a transaction
* Don't end a transaction when a Goto happens because of a paste-script directive ( @{ or @} ).
I want the change to not alter data, so use a `NoDataChangeDeltaModel`
I want the change to be tracked, so have it be part of the history.
This requires the ability to insert custom tokens into the history.
TextBox keeps track of its own Undo/Redo stack. Normally this is good, but it gets in the way of the `ChangeHistory` object. So disable it.
Bug: Whenever the TextBox changes the selection in the main window, that suddenly counts as a new transaction. This means that as the user is typing in changes, each character gets registered as a separate change. This isn't desirable. Instead, batch the changes together such that any caret movement in the textbox won't cause a new transaction.
Pull the completion code into a new type.
This is actualy way better organized now. But a lot of code had to move, so I'm not confident that I didn't introduce any bugs.
