Community
Participate
Working Groups
Example: public class Test { public void aMethod() { Object anObject = new Object() { boolean aVariable; }; } } When I click source->format and a have the 'never join lines' checkbox on in my code formatter, my class is turned into: public class Test { public void aMethod() { Object anObject = new Object() { boolean aVariable; }; } } So the first brace of my anonymous inner class is moved to the right. When I uncheck 'never join lines' this doesn't happen.
Which build id?
Build id: I20090611-1540
Reproduced even using M20090807-0800, hence this is not a duplicate of bug 283467...
Created attachment 144516 [details] Proposed patch This patch adds a new flag on alignment to know whether the break indentation should be used when keeping existing break lines. This is typically the case while preserving line breaks inside a binary expression alignment. Currently in all other alignment kind, the current indentation level is used instead...
Created attachment 144650 [details] New proposed patch This new patch also fixes potential issue with binary expressions other than string literal concatenation...
Olivier, I would like you to review this patch as I needed to change the builder.size() > 4 condition to builder.size() > 2 to make binary expressions formatted as soon as 2 terms are in the condition instead of 4... I do not understand the reason why the formatter should skip expressions with 2 or 3 terms, hence I changed it, but may be there's an important undocumented reason I'm currently missing...
As long as we can get a good formatting, I don't see anything wrong in changing this value.
Released for 3.6M2 in HEAD stream.
Verified for 3.6M2 using I20090914-1800 build
Verified.
I am using 3.6M2 now, build I20090917-0100, but the formatting is still broken. Formatting the original example with 'never join lines' on still gives the same result.
(In reply to comment #11) > I am using 3.6M2 now, build I20090917-0100, but the formatting is still broken. > Formatting the original example with 'never join lines' on still gives the same > result. I'm also using 3.6M2 and cannot longer reproduce. Could you attach your formatting profile?
Created attachment 149093 [details] My formatting profile Attached my formatting profile
(In reply to comment #13) > Created an attachment (id=149093) [details] > My formatting profile > > Attached my formatting profile OK, thanks for the input. So, I didn't investigate a lot but this is fixed in last I-build. IMO, your issue was certainly similar than the one I got when I opened bug 286912. So, closed as duplicate of that bug... *** This bug has been marked as a duplicate of bug 286912 ***
(In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=149093) [details] [details] > > My formatting profile > > > > Attached my formatting profile > > OK, thanks for the input. So, I didn't investigate a lot but this is fixed in > last I-build. IMO, your issue was certainly similar than the one I got when I > opened bug 286912. > > So, closed as duplicate of that bug... > > *** This bug has been marked as a duplicate of bug 286912 *** Ooops, forget this comment, bug 286912 was also targeted 3.6M2. So, I need to investigate a little bit more. However, as I cannot reproduce with HEAD, the good news is that it will be really fixed for 3.6M3. I just need to find which bug fix also fixed this issue...
Hmmm, it seems that I needed a coffee this morning as I can reproduce with HEAD... This is a tricky one as it's not reproducible with Eclipse built-in formatter profile + 'Never Join Lines' preference ON. After investigation, it appears that the difference comes from the Brace preferences? They are all set to 'Next line' in the given profile (except for Array initializers) although they are all equals to 'Same line' in the Eclipse built-in profile... I'm trying to figure out what could be the best fix for this peculiar issue...
Created attachment 149117 [details] Additional patch Do not print the comment before processing the opening brace fixes the problem. It's necessary to first print the new line (if any) and then after print the comment. With this print order, the formatter can keep the correct indentation on the new line (if any).
(In reply to comment #17) > Created an attachment (id=149117) [details] > Additional patch > Released for 3.6M3 in HEAD stream.
No change noticed while running FormatterMassiveRegressionTests with the patch vs v_A13 for all full source workspaces...
With the released patch, running formatter massive tests with the bug profile has shown several instability (i.e. files having different formatting output while repeating it twice) in all the full source workspaces, e.g.: - 31 while running massive on an Eclipse 3.0 wksp (0 existing) - 93 while running massive on a Galileo wksp (47 existing) - 148 while running massive on a JDKs wksp (115 existing) Hence, some rework needs to be done to try to fix these instabilities...
Created attachment 150464 [details] New additional patch With this new patch I get the following instabilities: - 3 while running massive on an Eclipse 3.0 wksp (0 existing) - 29 while running massive on a Galileo wksp (47 existing) - 125 while running massive on a JDKs wksp (115 existing) which is of course not perfect but really better than previous patch behavior... So, I'll release it for 3.6M3 and I will continue to improve the behavior in this area...
(In reply to comment #21) > Created an attachment (id=150464) [details] > New additional patch > Released for 3.6M3 in HEAD stream.
>So, I'll release it for 3.6M3 and I will continue to improve the behavior in >this area.. Frédéric, is there a follow-up bug for that work?
(In reply to comment #23) > >So, I'll release it for 3.6M3 and I will continue to improve the behavior in > >this area.. > Frédéric, is there a follow-up bug for that work? I opened bug 293300 for this follow-up.
I don't why this bug was reopened...!?
Verified for 3.6M3 using I20091027-0100 Remaining issues will be verified once bug 293300 is fixed.
*** Bug 303107 has been marked as a duplicate of this bug. ***
