Summary: | [clean up] Running save actions on refactor | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | John Arthorne <john.arthorne> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | benno.baumgartner, Brian.Miller, daniel_megert, duffyjk, eclipse, irbull, jeffmcaffer, markus.kell.r, remy.suen |
Version: | 3.5 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | fix candidate | ||
Bug Depends on: | 195063 | ||
Bug Blocks: |
Description
John Arthorne
2008-08-18 13:57:13 EDT
>It would be cool if the "save actions" could also be configured >to run at the end of a refactoring on the modified files. Or move the save hook from the editor to file buffers which refactoring uses. Depending on the outcome of bug 195063 we might be able to do something for 3.5. Another idea we once had, a long time ago, was to run clean-up on commit. That way you can be sure to have "clean" code in your repository no matter what. Any thoughts on this getting fixed for Galileo. It keeps hitting us as we refactor large swaths of code... > It keeps hitting us as we refactor large swaths of code...
Just to clarify: I assume you would not only want this when the touched file is in the editor but also when it is not even open in an editor, right?
*** Bug 265576 has been marked as a duplicate of this bug. *** I could probably implement this in the RefactoringStarter (take the Change from the RefactoringWizard, collect affected CUs and run save actions on those) or by adding a special Change object at the end of the refactoring change tree. There's just one problem I don't have a good solution for, and that's Undo behavior. It's technically not possible to show the changes from the save actions already in the preview, so we would have to run them silently after the refactoring changes have been applied (like on Save in the editor). Now, if we include the save actions in the compound Undo for the whole refactoring, the user has no way to undo just the save actions (in the editor, the Save command adds 'Undo Save Actions' to the undo stack). But if we split it up into two undo operations, then this will cause confusion if a user runs a refactoring, invokes Undo, and then is surprised that the refactoring has not been undone (only the save actions have been reverted; to undo the refactoring, Undo needs to be invoked a second time). No time left but something we should follow up during 3.6. |