IMO, This is a bit odd I feel like the unnamed patterns should be indented further we can treat it as a RECORD_PATTERN_DEF child. So I think it should be indented a bit after the pattern. like the pattern is indented a bit after if

Show a snippet of what you think better indentation is (current versus yours).

I don't see an issue here (last example) since this is a wrapping of the previous line and all the _, are on the same level.

I could see

            ColoredPoint( //indent:12 exp:12
            _,  //indent:12 exp:12

needing to be indented more to:

            ColoredPoint( //indent:12 exp:12
                _,  //indent:16 exp:16

But indentation check has issues with double line wrapping. It doesn't understand nested expressions should be indented a second time and only do them one time.

        if (obj instanceof 
            ColoredPoint( //indent:12 exp:12
                _,  //indent:16 exp:16
                _,  //indent:16 exp:16
                _)) {} //indent:16 exp:16

I wanted it to be like this so basically a double-line wrapping yes, because it is nested inside the record pattern not the if.

But indentation check has issues with double line wrapping. It doesn't understand nested expressions should be indented a second time and only do them one time.

Then I think the current behavior is acceptable if we can't achieve a double line wrapping

I'm ok to leave it as it is for now.

same here for the record pattern components named or unnamed.

I think there is a conflict here ? ( 8 -> 12) then (12 -> 8)

ColoredPoint(_,_,_)  //indent:0 exp:12 warn
        )) {}  //indent:8 exp:12 warn

        ColoredPoint(_,_,_)  //indent:12 exp:12
            )) {}    //indent:8 exp:12 warn ( never satisified)

This needs to be a new issue if it can never be satisfied.

After looking carefully for this example.I think the problem is we have two parens on this line. one paren for the if and one for the record pattern.

The record pattern paren has to be on indent 12 and the if paren has to be on 8. so putting them on the same level will always produce a violation on one of them.

Sorry, there is no conflict here the check just requires a different indentation for each paren.

If you can never satisfy this so there is no violations then this IS an issue. All violations should be valid and should be solvable to some extent. Indentation is to guide users to correct indentation. It can't be correct if it is always wrong.

I just thought that if this conflict has a valid reason then this is not an issue.but yes users still face a violation that can't be solved
#15193