Community
Participate
Working Groups
For example, the code formatter gave me this: out .append("Very long text string ..."); which is just bizarre, because the line would have been shorter if the code formatter hadn't applied any line wrapping. Also, i have Indent on Column enabled and i see this a lot: someMethod( "value", anotherMethod( "long string value")); Whereas it should have been: someMethod("value", anotherMethod("long string value")); This only occurs when after formatting the line is still longer than the line width, but the extra line breaks don't shorten the line size and just add ugliness.
*** Bug 197155 has been marked as a duplicate of this bug. ***
*** Bug 196563 has been marked as a duplicate of this bug. ***
this is really a quite annoying bug if i may say so.. If the line can't really wrap, then wrap shouldn't happen. Personally i want never the first method call to wrap. So something like "never wrap first method and the rest as needed" if the first is a long string then do not wrap. Especially when sometimes the next sentence is even longer or gains only 1 or 2 chars.. also this shouldn't happen: xxx. yyy(somelong , but can be wrapped); that should always be xxx.yyy(somelong , but can be wrapped);
ok after some digging i found the solution for this one: out .append you just have to specify in Function Calss -> Qualified invocation that it shouldn't wrap. And if i also do that with Expression -> Assignments then eclipse doesn't wrap things that it shouldn't do for the most part.
It seems this is a general problem not specific to just Line Wrapping -> Function Calls -> Qualified For example: a( "hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii", ""); Any line wrapping which is set to "Wrap only when necessary" does not take into account the indentation after wrapping. An interesting note from the above example, function arguments are only wrapped if there are 2 or more.
Ownership has changed for the formatter, but I surely will not have enough time to fix your bug during the 3.5 development process, hence set its priority to P5. Please provide a patch if you definitely need the bug to be fixed in this version and I'll have a look at it... TIA
This bug in the formatter is a very annoying bug because it makes the code look so strange, pushes the code way over to the right side, and makes the formatted lines longer than the original. With the default values for the "Function Calls"->"Arguments" settings, which are "Wrap only when necessary" and "Default indentation" with the default indentation at 2 the preview window shows: /** * Arguments */ class Example { void foo() { Other .bar(100, 200, 300, 400, 500, 600, 700, 800, 900); } } The best work around I have found for this bug is to change the formatter setting value from "Default indentation" to "Indent by one". With this change the preview window shows: /** * Arguments */ class Example { void foo() { Other.bar(100, 200, 300, 400, 500, 600, 700, 800, 900); } } For some reason the formatter is able to format the code correctly without adding all the strange extra white space and selecting incorrect wrap points when the wrap indentation is set to 1. This work around only indents the wrapped lines by one level instead of 2 levels, but the resulting code at least looks reasonable. The formatter appears to work correctly with the wrap indentation set at 1 but ends up with the incorrect formatting when the wrap indentation is set at 2. Perhaps knowing this might help in tracking down and fixing this bug.
(In reply to comment #7) > This bug in the formatter is a very annoying bug because it makes the code > look so strange, pushes the code way over to the right side, and makes the > formatted lines longer than the original. > Thanks for having pointing this... I missed this duplicate bug. > With the default values for the "Function Calls"->"Arguments" settings, which > are "Wrap only when necessary" and "Default indentation" with the default > indentation at 2 the preview window shows: > Since 3.6M5, the preview is now what you were expecting: class Example { void foo() { Other.bar(100, 200, 300, 400, 500, 600, 700, 800, 900); } } *** This bug has been marked as a duplicate of bug 264112 ***
Verified for 3.6RC1 using Build id: I20100513-1500
