Improper indentation after a compound statement

[webczat]

If you write:

if (1 == 2)
return
//some other statement

the second line now seems to be properly indented, but the third one currently containing the comment does not have indentation shifted left then.

[eric-milles]

If you have:

if (a == b)
    return${cursor}

then type enter, how is the plug-in supposed to know that you have completed the return statement? It is just as possible that you add more to the return statement, since you have not included a semicolon.

[webczat]

well, in groovy I do not need semicolons, isn't it obvious for the plugin?
Actually I have tried adding a semicolon after return, but it still didn't shift left after enter

[eric-milles]

I understand that semicolons are optional. But in their absence, there is no clear way to determine the return statement is finished, unless the method in which that block is contained is checked for void return type. But the indenter does not look at context that much.

Ao, it may be obvious to you that in your one case, the next line is not a continuation of the return statement. But in general it cannot be unambiguously determined and to keeping the current indent level is what is implemented. You can always hit Shift-Tab or Ctrl-I.

[webczat]

understood. still, from what you say, it would seem that it should work as I want it to if I add the semicolon at the end of instruction, but it does not.

[eric-milles]

If you use a semicolon, that would indicate a complete statement. A change is required even to handle that. I was not implying that the semicolon case works that way already.

[webczat]

I understand.
Actually I believe that code like

return
1234

is not ambiguous and means two instructions, first return, then 1234. so I am not sure if the plugin would have to look for so much things to handle that properly, as it seems you can never break lines before an optional part of a statement or whatever, am I right?

[eric-milles]

You and I may look at the two lines and say it is unambiguous. But it is only the parser's interpretation that matters.

I have written this and got burned:

return x
    + y
    + z

Where x, y, an z are subexpressions like (1 + func()) or whatever. The parser was happy with "return x" followed by to unary plus expressions, regardless of my indentation.