[Feature]: Hanging indent formatting for parentheses & routine definitions/calls etc.

[steinhh]

Description

I would like to be able to format code like this:

PRO hanging_indent_test, a, b, c, d, e, f $
                         f, g, h, keyword = k, keyword2 = k2, $
                         keyword3 = k3
  local_var = k3

instead of this:

PRO hanging_indent_test, a, b, c, d, e, f $
  f, g, h, keyword = k, keyword2 = k2, $
  keyword3 = k3
  local_var = k3

and

  long_var_name = ( b + c + d + e + f $
                    + g + h )

instead of this:

  long_var_name = ( b + c + d + e + f $
    + g + h )

And something similar for structure definitions, e.g.,

  a = { MY_STRUCT, $
        b : 4, $
        c: 5 $
      }

and arrays:

  aaaa = [ 5, 3, 6, $
           7, 8, 8 ]

Why it Matters

I find such statements much more readable with hanging indents:

E.g., the keyword definition keyword3 = k3 gets entirely lost/confused with local variable assignments when formatted as is standard now.

This is the way idlwave-mode for emacs does it which presumably means there is a sizeable subcommunity that's used to it.

This is also the way a mathematician would write an equation (if there is enough space).

Suggested Behavior

See description.

This formatting style should/must probably become an optional choice, so as not to affect codebases using current formatting rules as a surprise. In fact, it may be an idea to have the option be called something along the lines of "emacs idlwave emulation", in case we find other things we miss :)

Alternate Behavior

Implement a directive "no-idl-format" which switches off automatic formatting for the next statement. Maybe also an on/off switch ("idl-format off" vs "idl-format on") to turn off formatting for a specific code section.

[znorman-harris]

In general, I think our goal with formatting is to not go too crazy with options for the style and spacing of your code.

However, I do think this option makes sense, especially if you are working with other languages like Python where this can be a common style for multi-line expressions.

With that being said, let me think about if this would fit into our current implementation or not. This might be a fair amount of work to make sure we handle all of our edge cases for formatting and different tokens that we have to handle, but it could turn out to be easier than that.