Community
Participate
Working Groups
Any possibility of turning off certain aspects of the code formatter? What I would like is the ability to format: public void testParse(){ String output=parse(new TestSystem()); assertEquals( "Plant,Wood,Plastic,Total,Last Updated\n" + "ConcordNorthPlant,450,720,1170,"+new Date(104, 10, 7)+ "\n" + "" + "", output); } into public void testParse() { String output = parse(new TestSystem()); assertEquals("Plant,Wood,Plastic,Total,Last Updated\n" + "ConcordNorthPlant,450,720,1170," + new Date(104, 10, 7) + "\n" + +"" + "", output); } In other words, the ability to tell the formatter to leave line splittings alone, but still format everything else. The current behaviour (as far as I can tell) is that it will always do something; remove all line breaks, add all possible line breaks, something in between, etc. There is no setting which allows one to disable line break formatting without disabling the entire formatter. This becomes quite annoying when one wishes to have large amounts of text formatted one line per editor line, and that text includes several components; or when one has several method calls nested, which one wishes to format in a way to clarify the intent. Although I would prefer a separate "Leave Alone" value for each option in "Line Wrapping", the "Enable Comments Formatting" checkbox under "Comments" would be good enough.
Ignoring of course the [+ + ""] typo :p Also, for the sake of example, the current behviour would format it as assertEquals("Plant,Wood,Plastic,Total,Last Updated\n" + "ConcordNorthPlant,450,720,1170," + new Date(104, 10, 7) + "\n" +"" + "", output);
Deferring post 3.1
*** Bug 120767 has been marked as a duplicate of this bug. ***
Bug 120767 is different to this bug. it requests a method of marking a block of code NOT FOR FORMATTING. if that is how you intend to solve this bug, so be it, otherwise we are talking about two different things. i'm happy with how the code formatter works (other than comment formatting Bug 73580), it's just that certain blocks don't lend themselves to formatting conventions.
*** Bug 141674 has been marked as a duplicate of this bug. ***
*** Bug 152914 has been marked as a duplicate of this bug. ***
*** Bug 180174 has been marked as a duplicate of this bug. ***
For an additional aspect, it may be useful to specify methods of classes (and their descendants) which should be excluded from line wrapping as source code is formatted. As an example, the Java tutorial on using the GroupLayout recommends to indent the source code incorporating classes related to GroupLayout (i.e. the subclasses of Group): <http://java.sun.com/docs/books/tutorial/uiswing/layout/group.html> In the following example taken from the site above, "layout" is an instance of GroupLayout: layout.setHorizontalGroup( layout.createSequentialGroup() .addComponent(c1) .addComponent(c2) .addGroup(layout.createParallelGroup(GroupLayout.Alignment.LEADING) .addComponent(c3) .addComponent(c4)) ); It may be obvious that the manually formatted source code reflects the structure of the actual layout object and enhances the understanding of that particular piece of code. My suggestion would be to let the user define methods (or classes) whose calls should at least not be wrapped.
Reopen to close as a dup of bug 27079
*** This bug has been marked as a duplicate of bug 27079 ***
I believe that this should not have been marked as a duplicate of bug 27079. 27079 proposes a particular solution to this problem, and from the comments in 27079 it has been closed as WONTFIX because that particular proposal is not considered a good solution. The essential problem of needing an option to prevent the formatter from removing new lines remains, and ought to be addressed in an open enhancement request. This bug adequately describes the problem, and so I suggest it should be reopened.
This isn't the most carefully thought through proposal, but could there simply be a checkbox in the formatter along the lines of "Ignore statements with unnecessary new lines". Then if the formatter encounters a statement which it would normally format by removing new lines, it would instead ignore it. This would effectively give the user a way to over-ride the formatter in specific cases without needing to pollute the code.
Agreed that this is not strictly a dup of bug 27079. Reopening.
I think the most common issue with wrapping/new lines is when you have consecutive String Literals being concatenated, String Literals are broken up for readability (think SQL statements). If we wanted it on one line, we can easily combine them into one literal String a = " foo " + " moo " + " foo " + " moo "; String a = " foo moo foo moo "; How about adding options like: Wrap when concatenating consecutive String Literals Wrap when necessary or when concatenating consecutive String Literals
(In reply to comment #14) > How about adding options like: > > Wrap when concatenating consecutive String Literals > Wrap when necessary or when concatenating consecutive String Literals Please, no need for half-baked solutions for specific cases. I personally more like example of GroupLayout code, or more generally, popular now "fluent interfaces". In these cases you (or your visual GUI designer) now better how to format, so would be good to have some line comments (something like CheckStyle does?) to begin/end protected code block. More interesting approach (may be even not conflicting) is ability to specify formatting rules not for Java syntax (i.e. on level of statements, expressions, etc), but for code semantics! For example, for this GroupLayout example: layout.setHorizontalGroup( layout.createSequentialGroup() .addComponent(c1) .addComponent(c2) .addGroup(layout.createParallelGroup(GroupLayout.Alignment.LEADING) .addComponent(c3) .addComponent(c4)) ); would be good to specify somehow that createXXXGroup() should increase indentation on one level. Such "semantics specification" could be done by library author in form some XML descriptor near to class or may be annotations directly in source of library.
I would suggest that it is absolutely vital that a solution is lightweight for the user. Having to define specific indentation rules for specific tyes of code sounds horrendous to me - far too much work. Equally, the idea that when writing a library you have to attach annotations or an XML file in order to tell Eclipse how to format it (when people have different ideas about formatting anyway!) seems crazy. As I said previously, the simple solution would surely be to provide an option for the formatter to leave both indentation and linebreaks alone when the user has added "unnecessary" linebreaks from the perspective of the formatter.
(In reply to comment #16) > I would suggest that it is absolutely vital that a solution is lightweight for > the user. Having to define specific indentation rules for specific tyes of > code sounds horrendous to me - far too much work. Equally, the idea that when > writing a library you have to attach annotations or an XML file in order to > tell Eclipse how to format it (when people have different ideas about > formatting anyway!) seems crazy. When you write some fluent interface, you DO know how it should be used and formatted. In any case, for newbie of this interface any good formatting will be helpful, even if it is not strictly follows to the personal tastes of user. If you designed fluent interface (not easy!), implemented it and now going to use widely (in other case, why did you create it?), then it is better to help yourself (or your users) by giving automatic formatting. Speaking them: Sort it out yourself, I'm not going to help you with formatting all this spaghetti of method invocations... - not very good move... XML is just one possible way, for developers of fluent interfaces annotations are probably more convenient. > As I said previously, the simple solution would surely be to provide an option > for the formatter to leave both indentation and linebreaks alone when the user > has added "unnecessary" linebreaks from the perspective of the formatter. We already have such ability - just don't format compilation unit, format only needed parts. May be also "Format edited lines" in "Save Actions". But "help" and "not hurt" are different things.
Created attachment 107260 [details] JPEG of Formatter Line Wrapping tab in Dialog A screenshot of the Line Wrapping tab in the Code Style Formatter dialog.
Hi, Simply having a "None" choice in the drop down list of choices would satisfy me. For example, I could select "None" for Array Initializers Line Wrapping and manually format these Array Initializers. This will probably satisfy only me, but would it be difficult to support "None" as a choice in all the format drop down lists? Thank you, Don
Comment on attachment 107260 [details] JPEG of Formatter Line Wrapping tab in Dialog A screenshot of the Line Wrapping tab in the Code Style Formatter dialog.
Are there any better solutions than this? // The commented endings are a strange workaround to prevent Eclipse // from reformat this code. layout.setHorizontalGroup( // layout.createSequentialGroup() // .addComponent(c1) // .addComponent(c2) // .addGroup(layout.createParallelGroup(GroupLayout.Alignment.LEADING) // .addComponent(c3) // .addComponent(c4)) // );
Did you try the new option "Never join lines" ?
Hm, I just updated to the latest RC and tried it. It's not perfect but ok. Thanks.
Looking at the comments history, it sounds clear to me that the issues described here are solved by the 'Never Join Lines' preferences, hence set as duplicate of bug 198074. *** This bug has been marked as a duplicate of bug 198074 ***
I disagree that this is resolved or a dup of 198074. This is a separate issue from 198074 even if some of the behavior described is fixed by "never join lines." This bug is to disable any or all aspects of code formatting, not just joining lines. ("Never join lines" doesn't solve my problem if, for example, Align Fields in Columns is the formatting I want to suppress.) Further, the fix to 198074 is scoped globally, while this bug is scoped at a single region of a single file. (What if I don't want to enable "never join lines" but want behavior explicit to a single function?)
Then this is a duplicate of bug 27079. *** This bug has been marked as a duplicate of bug 27079 ***
Verified for 3.6M6 using build I20100305-1011.
Verified.
