Community
Participate
Working Groups
The in addition to settign line length, the user should be able to set how to wrap things similarly to the way jalopy does now (but better naturally. =)) You should be able to tell the formatter to wrap the extends keyword down if there are more extends types than can fit on a line and same with throws and implmenets. In addition the wrapping of method call chains should be configurable. I should be able to enter: foo.bar().xmeth().yMeth(); and come out with: foo.bar() .xmeth() .yMeth(); In addition the parameters should be able to wrap if exceeded and deep indent.
Another nice option would be to indicate that the code formatter should be less wasteful of the vertical space. At the moment, following is the result of the code formatter: private static final String[] ACCEPTABLE_NAMES = new String[] { "ABIS", "ING", "DEXIA", "Fortis", "Nationale Bank België", "Studio100" }; I would like to see the following: private static final String[] ACCEPTABLE_NAMES = new String[] {"ABIS", "ING", "DEXIA", "Fortis","Nationale Bank België", "Studio100"}; or something very similar to it. Eclipse version: 3.0M4 on Win 2000 (Build id: 200310101454)
Did you enable the new formatter? Go to Preferences>Java>Work in progress.
<blush>Ooops</blush> This is the result with the new formatter: private static final String[] ACCEPTABLE_NAMES = new String[]{ "ABIS", "ING", "DEXIA", "Fortis", "Nationale Bank België", "Studio100"}; Incredible work. Thanks and sorry for disturbance. :-)
Ok to close then?
I don't know about Robert's request, but for me most of it seems solved. I will check some more during the weekend (found a couple of things/details and want to bundle them together as test cases).
Here are some tests I did and which turned out strange results. All line lengths are set to 72 characters (print margin, max. code line length, max. comment line length). Tab length is 4. First a case where we go over the line length: // - 1 ------- 2 ------- 3 ------- 4 ------- 5 ------- 6 ------- 7 // 89012345678901234567890123456789012345678901234567890123456789012 private static final String[] UNACCEPTABLE_FIRST_NAMES = new String[]{ "Paul1", "1Paul", "-Paul", "Paul-", "2", "Paul@some"}; Here, we clearly pass the indicated line length and, furthermore, the formatting of the assertEquals method is a bit weird. // - 1 ------- 2 ------- 3 ------- 4 ------- 5 ------- 6 ------- 7 // 89012345678901234567890123456789012345678901234567890123456789012 public void testPersonEquality() { try { Person p1c = cloneNewP1(); Assert .assertEquals( "Two person objects with same name and pno are not equal", p1, p1c); } catch (MalformedNameException e) { Assert.fail("Unexpected MalformedNameException"); } catch (WrongPersonNumberException e) { Assert.fail("Unexpected WrongPersonNumberException"); } } A case where the line is cut on character before the indicated maximum line length: // - 1 ------- 2 ------- 3 ------- 4 ------- 5 ------- 6 ------- 7 // 89012345678901234567890123456789012345678901234567890123456789012 String[] s = {"18", "bb", "cc", "dd", "ee", "ff", "gg", "hh", "ii", "jj", "kk", "ll", "mm"}; String[] st = {"19", "bb", "cc", "dd", "ee", "ff", "gg", "hh", "ii", "jj", "kk", "ll", "mm"}; Sometimes, code is touched which does not need to be formatted. The unformatted code (remember: tab is 4 characters): } catch (WrongPersonNumberException e2) { // ignore expected exception } The formatted code (1st time formatted): } catch (WrongPersonNumberException e2) {// ignore expected // exception } The formatted code (formatted above a second time): } catch (WrongPersonNumberException e2) { // ignore // expected // exception } The formatted code (formatted a third time): } catch (WrongPersonNumberException e2) { // ignore // expected // exception } After this third time, the formatting stays stable. With one indentation level less, it does not jump around so much. I hope I'm not veering to much off topic here.
Reconsider post 3.0.
*** Bug 65974 has been marked as a duplicate of this bug. ***
This can be done with wrap on columns but it doesnt work because of bug number 49896. If tabs are on, nothing lines up. Reopened in accordance with re- opening 49896.
Deferring post 3.1
Deferring BASIC and CORE formatting code is not a good idea.
The focus right now is on performance. Nothing prevents you from providing patches.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
