Subject: Undo/Redo comments
I am not on the mailing list but I want to put in a few comments about the
undo/redo proposal. Please forward the comments below to the group.
In summary, I fundamentally disagree with the idea that maintaining a
single stack for undo/redo across the workbench is the correct approach.
The workbench is not only an MDI application; in fact, it is a
multi-application platform on which unrelated applications will be running
at the same time. For instance, a user can have the Java editor and an
Icon editor each having open resources in the workbench at the same time.
By having a single undo stack across the workbench, we are forcibly
serializing all the action that the user performs within the workbench.
Consider the case when the user works on the Java editor, then the Icon
editor, then the Java editor again. Say now that the user needs to undo
the action taken in the Icon editor. With the single stack implementation,
the user must undo the last action performed on the Java editor. This is
clearly not the expected behavior because the user perceives the editing
performed in the Java editor as completely separate and unrelated actions
from the editing performed in the Icon editor. In other words, the editing
in the Java editor and the Icon editor are *parellel* tasks; and, as such,
require their own undo stacks.
RG> I agree this is the main problem case with a global undo stack.
You are definitely right in anticipating that there will be cases where
multiple actions performed across different editors constitute a single
logical task. However, this is probably not the norm, and in such cases we
would expect the participating editors to implement a stack-sharing
mechanism themselves. In fact, we already implement a similar scheme
RG> Could you give me some more details? Do you have multiple editors editing the same model? Do you see a similarity between what you are doing and the java refactorings?
Lastly, putting undo/redo actions on the workbench stack means that the
actions can out-last the life of the editor that contributed them in the
first place. There will be also problems when we save resources in the
editor -- how much of the stack are we going to flush? What if there are
other commands sitting on top of the commands contributed by the editor
performing the save?