Add support for nonlinear undo/redo (clones don't currently handle undo/redo correctly)

[JordanMartinez]

#232 (solution to #152) has been implemented. However, as noted by Tomas:

If the document is edited from both areas, undo will not work very well. One area's undo will be regarded as a new edit in the other area. It is a complex problem on its own, so for now I would just say that such a use is not supported.

[JordanMartinez]

I think the only way to account for this is to use one UndoManager that is shared between multiple StyledTextAreaModels. However, the tricky part lies in making sure all the other Models' getUndoManager() returns the same undoManager after one of them sets it to something else.

So, it seems like the best way to get around this is to wrap the UndoManager in wrapper class. See my betterCloningUndoing branch for an example of this.

However, there is an additional problem to solve. As of now, when the undo manager is created, it is passed a lambda that calls the replace() method of the StyledTextAreaModel that initially constructed it when a change is re-done.

So, if there are three StyledTextAreaModels, two of which are clones of the original....

StyledTextAreaModel initial;
StyledTextAreaModel clone1;
StyledTextAreaModel clone2;

....when clone1 or clone2 call getUndoManager().undo(), it is initial whose replace() method is called, not either of the clones.

So, what happens when initial gets disposed? When redo() is called, the disposed and thus garbage-collected initial won't exist and the attempt to call its replace() method will result in a NullPointerException.

[JordanMartinez]

The only way around this second part is if the apply part of createRich/PlainTextChange(UndoManagerFactory factory) doesn't rely upon StyledTextAreaModel's code in any way. In this way, it would need to actively call EditableStyledDocument's code and any caret/selection values would need to be updated via the code that updates these values when EditableStyledDocument's plainTextChange emits a new change.

[TomasMikula]

The same effect as by sharing an UndoManager can also be achieved by only one of the areas having a real UndoManager and the others having a fake one:

area.setUndoManager(UndoManagerFactory.zeroHistoryFactory())

Then no undo/redo will be available on the other areas, but the keyboard shortcuts can be overridden to trigger undo/redo on the area with the true UndoManager.

[JordanMartinez]

What happens when the initial area is disposed though? And doesn't that limit the developer if they want to be able to undo something using either of the areas?

[TomasMikula]

What happens when the initial area is disposed though?

Yeah, that would be a problem.

And doesn't that limit the developer if they want to be able to undo something using either of the areas?

The developer would have to know to call undo() on the correct area.

When first implementing the undo functionality, I almost wanted the UndoManager to live outside the StyledTextArea. I think in the end the main reason why StyledTextArea holds a reference to UndoManager was to have the expected behavior for Ctrl+Z etc. out of the box. Maybe it's time to rethink this.

[JordanMartinez]

What if it was placed within EditableStyledDocument? Even the code I've implemented in my branch could be refactored to place it there.

[TomasMikula]

Sorry for not being responsive. The reason is that I don't know a good solution off the top of my head, and I didn't have time to think deeply about the problem.

Putting UndoManager inside EditableStyledDocument has its own problems. For example, we will then never be able to include selection in the undo/redo, if we ever decide to implement it (and some editors do that).

Another desired feature would be that in one view, you would undo/redo only the edits made in that view. And the other view would undo/redo its own edits. So at least the UndoManager would need to distinguish the origin of the change (this applies whether there is a shared UndoManager or two separate ones). With this feature comes another complication. It is no longer sufficient to store edits as a linear sequence (possibly tagged by origin), as is done by UndoFX, but rather as a directed acyclic graph, in order to not impose some arbitrary ordering on edits that are independent (and thus can be undone independently of each other).

And then someone will come and want to implement a collaborative editor on top of RichTextFX. That necessarily means there will be asynchrony involved, which opens up the possibility of conflicts, so they will need a mechanism to resolve conflicts.

I don't think we can or should resolve all these problems in RichTextFX. I think the best we can do is put the user in charge, by pushing the undo/redo functionality out of StyledTextArea, with convenient factory methods that preserve the current Ctrl+Z behavior.

[JordanMartinez]

Sorry for not being responsive. The reason is that I don't know a good solution off the top of my head, and I didn't have time to think deeply about the problem.

No worries! :-) You're busy and I didn't realize just how complicated the implications could become

I don't think we can or should resolve all these problems in RichTextFX. I think the best we can do is put the user in charge, by pushing the undo/redo functionality out of StyledTextArea, with convenient factory methods that preserve the current Ctrl+Z behavior.

So, you're suggesting something like a "plug-in" sort of idea...? We can provide the current version of UndoFX as a basic "undo manager plug-in" but allow others to develop their own outside of RichTextFX. Thus, the way the undo/redo is handled is determined by the developer.

Edit: Perhaps "plug-in" isn't the best term to use for the idea your suggesting. However, I get the basic idea of what you're proposing.

[JordanMartinez]

Putting UndoManager inside EditableStyledDocument has its own problems. For example, we will then never be able to include selection in the undo/redo, if we ever decide to implement it (and some editors do that).

So, it should remain inside StyledTextAreaModel as it does now.

It is no longer sufficient to store edits as a linear sequence (possibly tagged by origin), as is done by UndoFX, but rather as a directed acyclic graph, in order to not impose some arbitrary ordering on edits that are independent (and thus can be undone independently of each other).

Doesn't this necessarily mean that UndoActions#undo and UndoActions#redo should include the StyledTextAreaModel that called the undo as an argument? Then, if one does want to use a shared UndoManager for handling a directed acyclic graphic undos/redos, they already have the foundation upon which to build their custom handling.

public interface UndoActions {
    public void undo(StyledTextAreaModel model) { getUndoManager().undo(model); }
}

However, as soon as we go that direction, now we run across the requirement of using generics: if one subclasses StyledTextAreaModel and provides some other functionality that is relevant to that model, a generic would be necessary to return the correct object without needing to cast it to its actual type:

public class ModelSubclass extend StyledTextAreaModel {
    // class content...
}

public interface UndoActions<PS, S, M extends StyledTextAreaModel<PS, S>> {
    public void undo(M model) { getUndoManager().undo(model); }
}

Adding another thought: Additionally, if we go that route, now UndoFX doesn't support that. It's #undo doesn't take any arguments. We could write a subclass of UndoManagerImpl within RichTextFX and add that functionality, but then we have an #undo method that might be mistakenly called.

[TomasMikula]

So, it should remain inside StyledTextAreaModel as it does now.

Or maybe further out, to StyledTextArea.

Doesn't this necessarily mean that UndoActions#undo and UndoActions#redo should include the StyledTextAreaModel that called the undo as an argument?

That would not be necessary, or desired. (Why would a user calling StyledTextArea#undo have to pass in something?)

if one subclasses StyledTextAreaModel

I'm not yet really on board with allowing subclassing of StyledTextAreaModel. I somewhat lost track here, why is it even public?

[JordanMartinez]

Or maybe further out, to StyledTextArea.

Isn't that breaking separation of concerns? UndoManager seems to operate on the model, not necessarily the view. Why stick it inside the view?

I'm not yet really on board with allowing subclassing of StyledTextAreaModel. I somewhat lost track here, why is it even public?

I was thinking in terms of separation of concerns. Why store model-content of a subclass of StyledTextArea within that subclass? Shouldn't it be stored in a subclass of StyledTextAreaModel?

That would not be necessary, or desired. (Why would a user calling StyledTextArea#undo have to pass in something?)

I was thinking of an approach where the clones share one UndoManager. The public API for StyledTextArea would still show undo() without any arguments. However, the implementation of it within the StyledTextAreaModel would need to call UndoManager.undo(source) where source is the model. I saw that as necessary so that if there were multiple views of the same document, the shared UndoManager would know which area's undo history to use to undo (or redo) some action.