Community
Participate
Working Groups
Version: 3.5.0 - Build id: I20081209-0100 With formatter preferences set to: org.eclipse.jdt.core.formatter.join_wrapped_lines=false org.eclipse.jdt.core.formatter.join_lines_in_comments=false The following code: public class X { void foo() { System.out.println() ; } } becomes: public class X { void foo() { System.out.println(); } }
Not even sure if it would make sense to preserve... could be argued to be a feature.
The line breaks are only preserved when there is a line wrapping involved. In this case there is no line wrapping, so the trailing semicolon is moved to the end of the statement. Personally I don't want it to be preserved in this case.
(In reply to comment #2) > The line breaks are only preserved when there is a line wrapping involved. In > this case there is no line wrapping, so the trailing semicolon is moved to the > end of the statement. > Personally I don't want it to be preserved in this case. > I do not want to preserve it either (not only to avoid to fix the bug...<g>) Dani, what's your mind?
If I enable that preference I expect no lines to be joined. However, as Philippe reported: it is a minor issue.
For me the intent of this new option was never to preserve the line break in this situation. If this is the case, then I don't want this new option. The purpose of this new option is to preserve line breaks inside line wrapping to make it possible for the user to "wrap" the long lines as he/she expects them to be wrapped and preserve this wrapping during formatting. Maybe we should rename the option. I don't see the point of using this option when no line wrapping is involved. Having the behavior described in comment 0 would be a bug for me, not a feature!
My point is that a normal user would never write code like in your example and if he really did then he wants it preserved.
Then this should be a new option.
I don't want it mixed up with the current option used in line wrapping.
Olivier, are you really having/writing code like that so that you are affected by this?
I hope not, but I don't want that kind of line breaks preserved. Ever! It is just ugly and pointless. You might have that kind of line breaks not on purpose by editing some code and having an extra-line break just before the semi-colon. On the next formatting, I don't want to preserve it even if this option is set to false, because I have some long lines that the code formatter doesn't handle the way I like them.
Don't get me wrong I can live with both behaviors. I just expressed my expectation, like you did yours. I suggest that we ask those that really use and requested the new feature i.e. poll in bug 198074.
Frédéric, please check if this is still a problem.
I personally agree with Dani: "... a normal user would never write code like in your example and if he really did then he wants it preserved." Also "it is a minor issue" we can just ignore.
My point of view is that the "Join lines option" should only be used in the context of line wrapping. The biggest issue is when line wrapping is involved and user formatting is lost. In the test case in comment 0, I certainly don't want the line break to be preserved.
(In reply to comment #14) > My point of view is that the "Join lines option" should only be used in the > context of line wrapping. The biggest issue is when line wrapping is involved > and user formatting is lost. > In the test case in comment 0, I certainly don't want the line break to be > preserved. But, when the formatter is going to remove the line break in this special case, aren't we also in the context of line wrapping ? I don't see in which case the formatter thinks that it is in "line wrapping" context or not. By the way, a ";" alone on a line might be used by some developers to indicate explicitly that an IF or LOOP control statement is followed by an empty statement, e.g.: if (doSomething()) ; else react(); for (...) ;
I am one who requested bug 198074 to be fixed, primarily to preserve multi-line concatenated strings. We had one class we could never use the formatter with because it contained all our SQL queries. As mentioned in bug 198074, we only wanted it applied to line wrapping. Other newline rules set in the formatter should still be enforced, such as whether empty statements should be on their own line. The example given in this bug is technically manual wrapping, but I would not want it "fixed". If necessary, add another rule for no space between the end of a statement and a semi-colon, but I doubt there would be much demand for the reverse.
Empty statements are handled already. There is no problem with this as far as I know.
I suggest to close this as WONTFIX. To clarify the behavior we can change the UI preference to "Never join already wrapped lines".
(In reply to comment #18) > I suggest to close this as WONTFIX. To clarify the behavior we can change the > UI preference to "Never join already wrapped lines". +1
> To clarify the behavior we can change the >UI preference to "Never join already wrapped lines". Done.
Closed as WONTFIX
Verified for 3.6M5 using Build id: I20100122-0800
Verified.
