Code Formatter misbehaves in some cases

use the attachment of STS-1193 to reproduce

Thanks for that Bootstrap.groovy file.

I played around with that a little. It looks like the problem happens when we place a
def someVar = ["unknown","female","male"] inside of a context where it is parsed as local
variable declaration.

It works fine when it is field def.

There are two separate issues here.

A while back I implemented some functionality to support the formatting of lists...
It will split up lists across multiple lines when the lists are "long".

The list in the example is considered "long" and if this breaking up of lists worked correctly it should have produces this:

def gender = [
    "unknown",
    "female",
    "male"
]

The criteria for determining "long-ness" are simple, the AST node of the list in question spans more than 25 characters. The example list is 27 characters. We could debate whether the list is really "long" and should be split. Maybe the number "longness" number ought to be bumped-up a bit.

However, there is the second issue of the last letters of "male" being lost. This is a bug in the
line splitter it incorrectly determines the place to replace whitespace between "]" and the preceding groovy token. This bug should definitely be fixed. Got a fix in my WS now.

I've got a fix, with some test-cases.

I've bumped up the "longness" number to 30 and also fixed the bug in the line-splitter. Bug was due to assuming that the GroovyToken's text value is actually related to the actual text of the token in the source code. It is not! So my calculation of the "end" of a token based on this text failed for some tokens (like a String token "male" who's length is 4 but it should have been 6. I'm now computing the end of tokens in a different way.

What still puzzles me is why the bug didn't manifest itself for field decls.
This suggests there may be a bug that the list formatting logic is, for some reason, not being applied to field decls. I'm going to investigate this before making a patch.

There was a bug in the AST visitor that the formatter relies on for finding list expressions. The visitor didn't go down inside the init expressions for field decls.

Patch with all the fixes described above is attached.

Patch is applied and committed.

OK to close?

Closing this. If more issues with formatter mollesting the code, they can be opened as new issues.