Community
Participate
Working Groups
What about the following options: (1) - "Automatically Organize Imports" (before "Save" and/or "Code Format") (2) - "Save editor after Code Format" (3) - "Automatically Format Code before Save" (4) - "Automatically Save after Organize Imports" The following two patterns happen quite often: enter new code ... (if one expects errors ;-)) "Add Imports" ... then "Format" ... then "Save" or enter new code ... then "Save" ... (if there're any errors) "Add Imports" ... then "Format" ... then "Save" It would be nice if one just had to press the "Save"-Hotkey or the "Code Format"-hotkey (or another hotkey/menu-item) and the code would be formatted/saved or imports organized/formatted/saved. If either the "Code Formatter" (which should never happen) or the "Add Imports" encounter any conflicts (in this "Action"-Combo") the user could be notified prior to the "Save". Sebastian Davids
most of the options make sense but can't be committed for 2.0
For the "auto-save after Organize Imports" I believe a strong case can be made that this is really just like refactoring, which always (am I right?) saves. One kind of refactoring is moving classes from one package to another, or renaming a package -- that requires the exact same sort of import-declaration adjustment, and indeed after such refactorings, Eclipse (1.0, build 137) seems to always save, which seems to always be good. Furthermore, under what circumstance would you ever want NOT to save after doing an Organize Imports?
>Furthermore, under what circumstance would you ever want NOT to save after >doing an Organize Imports? save can trigger an auto build and when I'm in the middle of editing the file and just did an organize import to get code assist to work I do not want that an auto build is triggered. Other suggestions are deferred for after 2.0
*** Bug 22741 has been marked as a duplicate of this bug. ***
*** Bug 27377 has been marked as a duplicate of this bug. ***
Chaning state from assigned later to resolved later. Assigned later got introduced by the last bug conversion and is not a supported Eclipse bug state.
*** Bug 23332 has been marked as a duplicate of this bug. ***
Is this request still on track? I am very interested in such a auto-format-on-save feature too. It's been a while since 2.0, so could this one be reconsidered for 3.0?
+1 for organize imports on save
*** Bug 69193 has been marked as a duplicate of this bug. ***
+1 for an option "Organize imports on save"
I don't agree with these changes. For 1/3 I agree with some hot key for Organizing Imports and Code Formatting but I don't believe it should be associated with "Save". First for a small example of where it is advantageous to have unused imports consider the case where while developing you're investigating the situation of using Foo or Bar. Now you have import Foo; import Bar; ... Foo f = new Foo(); f.doSomething(); //Bar b = new Bar(); //b.doSomethingSlightlyDifferent(); In this case one is doing a test run with Foo, next they may uncomment Bar and comment Foo and do a test run using that. However now this person has to undertake the additional step of using the quickfix to redo the import everytime, no major issue but a small pain especially if one has a number of possible supplies of Foo. Also consider the fact that "Save" is an operation that should really not be altering a file, it's better if it prompts but I'm still unsure as it would likely be a hit enter for yes style query which many people will accept out of habit then be wondering why their file just changed. As for 2,4 I don't agree since the Save triggers the automatic build and neither operation should change the functionality of the compiled program (I should state I haven't used Format Code) and unused imports shouldn't change the binaries as all (other than line numbers in debug info). An Automatic Build in this situation is completely unnecessary and is a big hinderance slowing down the machine (sometimes fairly significantly).
+1 for organizing imports on save from me, too. Is this issue still being worked on??
*** Bug 91904 has been marked as a duplicate of this bug. ***
*** Bug 99900 has been marked as a duplicate of this bug. ***
+1 Both organize and format on save. Make it optional - to be fair to the person with issue about comments. That way any file that I make changes to will always be correctly formatted.
*** Bug 127166 has been marked as a duplicate of this bug. ***
This has been marked "resolved" - resolution "later" for about three years. What will it take to reopend it?
Can we reopen this and re-describe it as 'perform code cleanup on save' and have it make it into 3.2 or failing that, at least 3.3?
as you wish :D
This is an interesting item for 3.3. We would appriciate if you leave the reopening of bugs to us. We try hard to keep the overview over the huge number of bugs and use 'LATER' also as way tof categorization. Simply add your comments to the bug, and we will reopen if you convinced us.
This is a duplicate of several reported bugs that have requested a "trim trailing spaces" option, but this bug never mentions trimming trailing spaces. FWIW, the option to trim trailing spaces should not be available only when saving.
*** Bug 54562 has been marked as a duplicate of this bug. ***
*** Bug 41320 has been marked as a duplicate of this bug. ***
This will be available in M3 and starting with N20061027-0010 as an experimental feature: you can select a clean up profile to be run on save. Enjoy!
*** Bug 22742 has been marked as a duplicate of this bug. ***
*** Bug 32245 has been marked as a duplicate of this bug. ***
But once needs to think how will this evolve if you decide to later implement 'Auto Save' funcitonality for the editors. I mean it would be kinda weird to have the formatting of a document change while the user is typing (due to auto save).
Can't comment on that since we currently have no idea how auto-save would work. If it directly saves the resource then the current solution wouldn't trigger the save participants.
