Bugzilla – Full Text Bug Listing
| Summary: | [implementation][api] Some operations do not allow compound undo support | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jim Adams <Jim.Adams> |
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, david_williams, Ernest.Pasour, gunnar, kitlo, pavery, thatnitind |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
I have the same problem. I am trying to insert some code, format it, and add some imports to the file. I would like this to be undoable in one operation. However, when I run the format action, it calls endCompoundChange() and blows my compound undo out of the water. Seems like this problem is getting to be a bit more of a problem. Anyone going to look at it? See also bug 89599 comment 20 for another comment on this. Both nested and overlapping compounds could be handles much better if the undo manager would track the currently open compounds. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Calling IRewriteTarget.beginCompoundChange() should place a single undo event on the undo stack. If IRewriteTartet.beginCompoundChange() is called again before endCompoundChange() is called then we loose the batching of the change. this can be seen with code like the following: IRewriteTarget target= (IRewriteTarget)editor.getAdapter(IRewriteTarget.class); if (target != null) { target.beginCompoundChange(); target.setRedraw(false); doc = target.getDocument(); } else { doc = editor.getDocumentProvider().getDocument(getEditorInput()); } // insert constructor IRegion reg = doc.getLineInformationOfOffset(offset); doc.replace(reg.getOffset(), 0, dropText); // add at the begining of the line // get line number of the end of the insertion int line = doc.getLineOfOffset(reg.getOffset()+dropText.length()); editor.getSelectionProvider().setSelection(new TextSelection(doc, reg.getOffset (), dropText.length())); formatAction.run(); This will result in 2 undo commands on the stack because the format action does its own beginCompoundChange(). I subclassed the DefaultUndoManager and used a counter to know when to actually called the default begin/endCompoundChange() methods. I know this can't be robust.