Indention based on square brackets

[lorenzwalthert]

Closes #206. Note that in the wake of this PR, I merged indent_curly() and indent_round() to indent_braces() to reduce code duplication, which in addition, indents based on [ also.
Note that the indention is not token-dependent (=constant), so

abjdsl[abc,
2]

becomes

abjdsl[abc,
  2]

And not

abjdsl[abc,
       2]

[lorenzwalthert]

@dracodoc does that look better? At least for now, I think we can't easily support token-dependent indention unfortunately.

[lorenzwalthert]

@dracodoc you can also use the option scope = "spaces" to use the initial indentions in case you don't agree with the token-independent indention.

[dracodoc]

Indentation is a complex issue. I think (, [ should have different treatment from { in general. Usually people will want indentation for (, [ to align with them, with the exception that too many new lines are needed because of long expression or already near the end of 80 characters, in that case it's understandable to indent further on left side.

Of course you may want to prioritize your tasks for now, so I think it's OK for now.

[lorenzwalthert]

Right. Token-dependent indention is explicitly not encouraged in the style guide we aim to support, see section 2.5 in the tidyverse style guide, so that's why it was/is not of high priority. I note though that many people use it and I hope we can support it in the future.

[dracodoc]

The style guide 2.5 seemed to be more about keep code within 80 characters for me, not how much indentation. The "bad" example is bad not because it indent to token, but it's over 80 characters. For statement within 80 characters, this usage should be perfectly fine.

do_something("that", requires, many, arguments,
             "some of which may be long")

The tidyverse style guide didn't give details for indentation (ony {} is mentioned). Generally one would indent similar elements to same indentation, so both examples below should be fine, since the 1st one have all items moved to next line, and the 2nd one have other items aligned to former items. Then you may have to use 1st format if you are over the 80 characters limit.

do_something_very_complicated(
  "that",
  requires = many,
  arguments = "some of which may be long"
)

do_something("that", requires, many, arguments,
             "some of which may be long")

[lorenzwalthert]

Well, one might argue. But it says

If a function call is too long to fit on a single line, use one line each for the function name, each argument, and the closing )

To me, this is unambiguous (although the examples are not, I agree). So we just felt we are going to implement this in a strict way, which is also the easiest thing to do anyway.

I think this line of argument is supported when looking at the next example:

# Good
paste0(
  "Requirement: ", requires, "\n",
  "Result: ", result, "\n"
)

This call is much shorter but the line is still broken after (.

[dracodoc]

I read it again, yes you are right about the function call style. There is no mention about [], though we can use same rule. If you are to follow the same style for [], the example in beginning should be

abjdsl[
  abc,
  2
]

instead of this.

abjdsl[abc,
  2]

Right?

[lorenzwalthert]

Right, thanks. I have not thought about this much actually since I hardly ever put an expression between [ and ] that is longer than one line.
@krlmlr What do you think is preferred?

a[first_long_expression_here, 
  second_long_expression_down_nere]

Or

a[
  first_long_expression_here, 
  second_long_expression_down_nere
]

I think the latter is preferred since consistent with the other brace expression rules we have.

[krlmlr]

I also prefer the second variant.