Community
Participate
Working Groups
We are now making regular use of the "save actions" in Equinox to ensure we keep our code formatted and imports organized. Overall this is working great. The only problem we notice is that when refactoring is used, files can be modified and never "saved", so these save actions never have a chance to run. Since we are no longer in the habit of manually formating and organizing imports, we end up with released code in the repository that doesn't match our conventions. It would be cool if the "save actions" could also be configured to run at the end of a refactoring on the modified files.
>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.
