Community
Participate
Working Groups
Build Identifier: It seems that a leading tab characters is counted as one unit/char when calculating the length of a line. It should be translated into the number of spaces that a tab character represents. (The following example was posted to the mailing list): According to FormatterTest.testIndentationAndLineWrap() in the test suite, for the input ----- "test indentation { void func(x:int,y:int,s:javalangString, foo:javasqlDate, blupp:mylongtype, msads:adshdjkhsakdasdkslajdlsask, x:x, a:b, c:d ); }" ----- if I use the following config: ----- c.setAutoLinewrap(30); // increment the indentation twice after a "{" c.setIndentationIncrement().after(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1()); c.setIndentationIncrement().after(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1()); ----- then the actual result is as follows: ----- 1234567890123456789012345678901 <-- column indicator test indentation { void func(x:int, y:int, <-- line length is 31, should have been wrapped s:javalangString, foo:javasqlDate, blupp:mylongtype, msads:adshdjkhsakdasdkslajdlsask, x:x, a:b, c:d); } ----- Reproducible: Always
Switching from enhancement to defect. I think this is more a defect than an enhancement.
Any chance this can be considered for 2.0 SR1?
Is it possible to target this for the next 2.0 SR? Thanks!
this is fixed in the new formatter infrastructure