Allow indentation after {, (, [, etc…

[elbrujohalcon]

Currently, default_formatter formats this code…

a_function(another_function(yet_another_function_with_a_long_name(Rec#a_record.a_field#another_record.another_field))).
…
    #a_record_with_a_long_name{a_field_with_a_very_long_name = #a_record_with_a_long_name{a_field_with_a_very_long_name = #a_record_with_a_long_name{a_field_with_a_very_long_name = b, c = d}}}.

…like this…

a_function(another_function(yet_another_function_with_a_long_name((Rec#a_record.a_field)#another_record.another_field))).
…
    #a_record_with_a_long_name{a_field_with_a_very_long_name =
                                   #a_record_with_a_long_name{a_field_with_a_very_long_name =
                                                                  #a_record_with_a_long_name{a_field_with_a_very_long_name
                                                                                                 =
                                                                                                 b,
                                                                                             c =
                                                                                                 d}}}.

I would like it to be formatted like this…

a_function(
    another_function(
        yet_another_function_with_a_long_name(
            (Rec#a_record.a_field)#another_record.another_field))).
…
    #a_record_with_a_long_name{
        a_field_with_a_very_long_name =
            #a_record_with_a_long_name{
                a_field_with_a_very_long_name =
                    #a_record_with_a_long_name{a_field_with_a_very_long_name = b,
                                               c = d}}}.

I'm aware that this is not easy because for erlprettypr to apply indentation when needed, the thing that stays in the row above (…( or …{) and the thing that goes to the one below must be considered separate words. That means that if the second one doesn't go below, it will be separated from the other one by a space. In other words, we'll end up with stuff like this…

a_function( another_function( "with", short, names)).
…
#a_record{ a_field = #another_record{ 'with' = {short, names}}}.

…which is undesired. But there might be some sort of alternative solution. We need to do more research.

[elbrujohalcon]

I've been doing a little bit more digging into prettypr, but to no avail… It looks like those spaces are practically unavoidable.
We might want to do one of these things…

1. Submit a PR to erlang/otp adding a way to tweak the behaviour of prettypr:hspace/0, prettypr:horizontal/1 and/or prettypr:expand_par/3 to our likings. This is slow.
2. Fork prettypr just like we forked erl_prettypr and "fix it" to our likings. This is sad.
3. Do the brutal approach and just remove all spaces after ( and { after formatting the code with prettypr. We need to do it… with extreme care… not to remove spaces from strings, comments, and whatnot. This is difficult and hacky.
4. Close this issue and leave things as they're now recommending people to just put things in variables or structure your code differently if they don't want to scroll right too much. This is sad.

@juanbono @diegomanuel @facundoolano @ElFantasma : opinions?

[michalmuskala]

Yes, the tendency to format code in a narrow column far to the right is a major issue of the algorithm used in prettypr. I don't think it can be avoided. It's one of the reasons I decided against using this algorithm for erlfmt.