Community
Participate
Working Groups
In Code Formarter->Line Wrapping -> Function Calls, I've got all items set to wrap only when necessary, but I don't think the code gets formated correctly, as line is break well before it's necessary. For instance, supose code: someObject.methodCall(arg1,arg2,arg3) Eclipse formats to someObject .methodCall(arg1,arg2,arg3) instead of someObject.methodCall(arg1,arg2, arg3) or similar...
Created attachment 17549 [details] Eclipse breaking the line on method invocation... This is the way eclipse breaks the line...
Created attachment 17550 [details] How eclipse should break the line This is the way I believe eclipse should break the line...
Is a fix for this expected to make it into 3.1?
This only seems to occur in particular cases: if the line is much too long, it doesn’t. For example, this: function.addTransition(FunctionInputTuple.getInstance( neitherButBothEncountered, foundX, foundY), foundDominating); function.addTransition(FunctionInputTuple.getInstance( neitherButBothEncountered, start, foundDominating), foundDominating); where the print margin line is here: ^ (i.e. between the ) and ; of the second line) gets reformatted to this: function .addTransition(FunctionInputTuple.getInstance( neitherButBothEncountered, foundX, foundY), foundDominating); function.addTransition(FunctionInputTuple.getInstance( neitherButBothEncountered, start, foundDominating), foundDominating); So if it rags far enough over the border, it is put on the next line first, which makes the breaking before the method invocation unnecessary. I can add screenshots if desired.
*** Bug 143634 has been marked as a duplicate of this bug. ***
We consider this a fairly serious problem with the formatter. We just recently told our development team that they must run any source files they plan to commit to our source control system through the formatter first. We are having to rethink that directive now that we've discovered this. Actually, the case I ran into is an extension of this problem, with even uglier results. In the case shown in bug 143634, it splits the line on the '.', but then the subsequent line is no closer to the left margin than it would be otherwise. So, the split does nothing to shorten the line; it simply splits it across two. We are hoping this fixed before 3.2 goes final.
This is too late for 3.2. We are in the end game. Only show stoppers will be considered at this stage.
Created attachment 45617 [details] Two rows that should wrap similarly Eclipse inconsistently breaks the two lines at the method invocation
*** This bug has been marked as a duplicate of bug 59891 ***
None of the samples in bug 59891 include the cases described in the comments here. Bug 5989 is about the aesthetics of where wrapping should occur. This bug is about unnecessary line wraps where the following line is indented to the same position that it was wrapped from. This provides no benefit.
(In reply to comment #10) > None of the samples in bug 59891 include the cases described in the comments > here. > > Bug 5989 is about the aesthetics of where wrapping should occur. > > This bug is about unnecessary line wraps where the following line is indented > to the same position that it was wrapped from. > This provides no benefit. > I agree with this remark. (In reply to comment #9) > > *** This bug has been marked as a duplicate of bug 59891 *** It was in fact more a duplicate of bug 264112, hence it's fixed since 3.6M5. *** This bug has been marked as a duplicate of bug 264112 ***
Verified for 3.6M7 using build I20100424-2000
