Community
Participate
Working Groups
Build ID: I20070621-1340 Steps To Reproduce: Simple example: 1. Enter in java the following: String x = "select x " + "from y " + "where z=a"; 2. format the code => Result: String x = "select x " + "from y " + "where z=a"; More information: This is the only reason why we hate using the formatter. It just doesn't respect the new lines entered by the developer. A new option respect new lines should be added and set default to true (I think all developers would agree on this) That's why I guess it's severity is high in regards of the formatter (if not even a formatter blocker) I guess some other formatter problems in the comments can be solved by doing the same thing (Add respect new lines option). Now I just turn the formatter for block and line comments off.
Note that only relates to wrapping, not the other parts of formatting. When formatting if bracers shouldn't be on the next line, the newlines shouldn't be respected. Only when applying the wrapping rule, newlines should be respected. Each wrapping option (including those of comments too) should have a checkbox: "do not remove existing newlines when wrapping". For example: if (enabled) { // we need x // we need a select return "select x " + "from X";} would become under a Sun's java coding conventions formatter: if (enabled) { // we need x // we need a select return "select x " + "from X"; } Currently it becomes something like: if (enabled) { // we need x we need a select return "select x " + "from X"; }
PS: IntelliJ idea 3, 4, 5 and 6 do this correctly out of the box :)
I do totally agree with this request. And this is THE reason I'm not using Eclipse to format my code. I've been using IntelliJ IDEA for a long time before switching to Eclipse when I moved to another company. IDEA is working just great: reindents lines, preserves developer's line splits. Here's another example : -----BEFORE----- public String toString() { return "YAD01: " + " nommbr='"+getName()+"'" + " nomgrp='"+getService().getArgtbl()+"'" + " typmbr='"+getMemberType().getArgument()+"'" + " srcpat='"+getPhysicalPath()+"'" + " nommdl='"+getModel()+"'" ; } -----AFTER (Ugly)----- public String toString() { return "YAD01: " + " nommbr='" + getName() + "'" + " nomgrp='" + getService().getArgtbl() + "'" + " typmbr='" + getMemberType().getArgument() + "'" + " srcpat='" + getPhysicalPath() + "'" + " nommdl='" + getModel() + "'"; } -----AFTER (ok)----- public String toString() { return "YAD01: " + " nommbr='" + getName() + "'" + " nomgrp='" + getService().getArgtbl() + "'" + " typmbr='" + getMemberType().getArgument() + "'" + " srcpat='" + getPhysicalPath() + "'" + " nommdl='" + getModel() + "'" ; }
See also this request from someone else: http://dev.eclipse.org/newslists/news.eclipse.platform/msg67607.html
Found same enhancement request: 99100 But this one is two years old and still in NEW status. Is this one going to have a bit more success ?
Wow, I thought I was just overlooking an option somewhere, wouldn't have thought this was actually a bug. I strongly agree, this is the #1 reason our developers are slightly hesitant to use the formatter. Indenting is OK, but there should be an option to not only "do not wrap" but also "do not collapse".
This is a formatter show stopper for us!
*** Bug 208451 has been marked as a duplicate of this bug. ***
Created attachment 83451 [details] spam my carbide ui can not open
Comment on attachment 83451 [details] spam (In reply to comment #9) > Created an attachment (id=83451) [details] > 1089048494500 > > my carbide ui can not open Looks like a spammer, see bug 210560.
Correcting this problem would also address another bugbear of mine. The formatter knows that it should not extend lines beyond a set width. However, it always puts the three elements of a "for" expression on a single line, even if they have been split by the programmer because the expression exceeds the allowed line length.
Time permitting for 3.4
*** Bug 213700 has been marked as a duplicate of this bug. ***
We ran out of time and we didn't get any help on this one. Deferring post 3.4
I hope this bug gets the attention it deserves for the next release. For me, personally, this is the number #1 bug in eclipse at the moment.
Geoffrey, the best way to get this bug fixed is to provide a good quality patch with the corresponding JUnit tests.
(In reply to comment #14) > We ran out of time and we didn't get any help on this one. Deferring post 3.4 > Our team of developers really wants to use the automatic formatting features to unify our code, but this bug is holding us up. Please make a serious effort to get this fixed as soon as possible. Since it was promised for 3.4, I would hope at least a patch would be available before the next major release.
(In reply to comment #16) > Geoffrey, the best way to get this bug fixed is to provide a good quality patch > with the corresponding JUnit tests. > That's true, but to be honest: I don't have the time. All my spare time goes into drools-solver (also an open source project). One has to make choices (and I only have to use Eclipse at work...). If anyone else does it, that person has my thanks :)
Marking as enhancement as this will require a new mode (controlled by an option) in the formatter to take the user's new lines into account.
*** Bug 201022 has been marked as a duplicate of this bug. ***
*** Bug 61511 has been marked as a duplicate of this bug. ***
*** Bug 196124 has been marked as a duplicate of this bug. ***
Frederic, please investigate for M4
(In reply to comment #23) > Frederic, please investigate for M4 > Should I also include fix for bug 96696 (same issue for comments)?
(In reply to comment #24) > (In reply to comment #23) > > Frederic, please investigate for M4 > > > Should I also include fix for bug 96696 (same issue for comments)? > Yes, that makes sense
*** Bug 99100 has been marked as a duplicate of this bug. ***
Created attachment 119360 [details] Proposed patch Fix consists in hacking the Scribe method which preserve empty lines. When no line is to preserve (which means that the formatter tentatively removes an existing line break), then add a new line if the formatter is inside a wrapping alignment _and_ the new preference is set. Note that the new preference default is false to preserve backward compatibility behavior. But does it make really sense although it seems that most of people think that the formatter is so bad without it...!?
Olivier, could you please review, thanks?
>But does it make really sense although it seems that >most of people think that the formatter is so bad without it...!? Is it currently possible to configure the formatter so that, e.g. this: public String toString() { return "YAD01: " + " nommbr='"+getName()+"'" + " nomgrp='"+getService().getArgtbl()+"'" + " typmbr='"+getMemberType().getArgument()+"'" + " srcpat='"+getPhysicalPath()+"'" + " nommdl='"+getModel()+"'" ; } gets produced? If so, I would expect that if I have such code: public String toString() { return "YAD01: " + " nommbr='"+getName()+"'" + " nomgrp='"+getService().getArgtbl()+"'" + " typmbr='"+getMemberType().getArgument()+"'" + " srcpat='"+getPhysicalPath()+"'" + " nommdl='"+getModel()+"'" ; and format it it would be formatted as configured and not left alone.
(In reply to comment #29) Preserving line breaks does not mean preserve wrong indentation. These are two separated points. Indentation is always fixed by the formatter; its value of course depends on statement and corresponding preferences. For example, for your test case: public String toString() { return "YAD01: " + " nommbr='"+getName()+"'" + " nomgrp='"+getService().getArgtbl()+"'" + " typmbr='"+getMemberType().getArgument()+"'" + " srcpat='"+getPhysicalPath()+"'" + " nommdl='"+getModel()+"'" ; it's possible to have the following formatter output: public String toString() { return "YAD01: " + " nommbr='" + getName() + "'" + " nomgrp='" + getService().getArgtbl() + "'" + " typmbr='" + getMemberType().getArgument() + "'" + " srcpat='" + getPhysicalPath() + "'" + " nommdl='" + getModel() + "'"; } by using the proposed patch and seeting '0' for 'Default indentation for wrapped lines'...
OK, so we could try to enable this per default - at least in the 'Eclipse' Profile.
+1. Fix looks good.
Released for 3.5M4 in HEAD stream.
Verified for 3.5M4 using I20081209-0100
Will this be backported to 3.4.x?
The change comes with an API addition (pref) which is not something we consider in maintenance streams. So the answer would be no go for 3.4.x (it isn't a critical bug fix, but a feature addition).
*** Bug 265192 has been marked as a duplicate of this bug. ***
I would like to know what all people interested in the 'Never join lines' option think about bug 258049... Do you think that the formatter should preserve such rare code patterns when the option is activated or should it ignore it instead and always join the lines in that case? Thanks in advance to let us know your mind about this issue by adding a comment to bug 258049 :-)
*** Bug 152444 has been marked as a duplicate of this bug. ***
*** Bug 76435 has been marked as a duplicate of this bug. ***
*** Bug 91902 has been marked as a duplicate of this bug. ***
*** Bug 98898 has been marked as a duplicate of this bug. ***
