Undo does not re-enable nodes

[amchiclet]

Sometimes when undoing changes, the editor successfully undoes the changes, but the tree nodes do not always get re-enabled.

One way to reproduce this is to wait for jolden-bh to finish the computation. Then apply all the changes. Then go to each changed file, focus on it, then press Ctrl-Z until there are no undoes left.

[amchiclet]

Looking closer into this, the problem is with the operationMap in ChangeUndoRedoSupporter.

It maps IUndoableOperation to MarkerResolutionTreeNode.

For some reason, after the first undo, one of the keys in the map changes. The toString() for that key before was:

{Change field next to @Nullable Body(org.eclipse.ltk.internal.core.refactoring.RefactoringUndoContext@716cb4c0,org.eclipse.core.internal.filebuffers.SynchronizableDocument@21046afa)

After the first applied undo, it became.

Change field next to @Nullable Body()

This is why it wasn't able to find the MarkerResolutionTreeNode associated with that undo operation.

The missing string seems to be the Context field in the Operation object. In our case, look at TriggeredOperations.

One idea would be to look at what causes the difference between the event for the change and its undo and use the stable part of the event in the map as the key for locating MarkerResolutionTreeNode.

[reprogrammer]

We need a way to find the MarkerResolutionTreeNode corresponding to a history operation event. It's hard to add additional data to a history operation event because this object is created in library. So, we're thinking of keeping some additional metadata, e.g., stacks, to be able to map a operation history event to MarkerResolutionTreeNode. We looked the existing data in the operation history event. It includes the change, the file that it affects, and the content stamp of the file. The content stamp of the file can be used to match a change and an undo change, but, it's not exposed by the existing classes. We considered keeping two stacks for changes and their undos, but, the challenge would be to make the stacks file-specific.

[amchiclet]

We might be able to get the modification stamp from the following method calls.

event.getOperation().getTriggeringOperation().getChange().getFile().getModificationStamp()

[amchiclet]

We switched to using the ContentStamp object as the key mapping to changes. The problem still persists. My guess is that there are different changes that have the same content stamp which then causes the previous entry in the map to be overridden.

We probably need more info than simply the content stamp to map to changes, such as the file path.