I'm not sure what you mean by "correctly". I think this is entirely invalid and looks atrocious.
I did not see any calls for action, rather the opposite from the core team.

In the end, it boils down to user preference, something that the formatter doesn't allow.

Disallowing such chaining would probably be best for readability.

Also here's a more widely accepted perception of "correct":
https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions

I think this is much more readable. Just look at the reformatted code in src/compiler/crystal/tools/expand.cr. In the current version it is difficult to spot where each indentation level belongs to. This is better with this PR.

Obviously such pieces should be formatted differently to be really good, but this is one step in the right direction.

This would be much cleaner:

expansion
  .expanded_sources
  .zip(expansion.expanded_macros)
  .each_with_index do |(expanded_source, expanded_macro), j|		                                    
    expanded_macro.each do |a_macro|
      name = a_macro[:name]
      # ...
    end
    io << "~> "
  end

I'm not sure what you mean with such chaining exactly, but I'm pretty confident that it shouldn't be generally disallowed.

I actually think it's less readable. Before everything fit in 80 columns, now you have to scroll right to see what's going on.

The current formatting is just fine.

I know, it's a personal opinion, and that's why we will never agree on this.

I also think this is worse. And I'm also glad crystals code base only changes formatting in one file, it means we don't have much code that's messy in this way.

I know, it's a personal opinion, and that's why we will never agree on this.

@asterite let me ask you a question then - which version would you prefer to write/see?

expansion.expanded_sources.zip(expansion.expanded_macros)
                          .each_with_index do |(expanded_source, expanded_macro), j|
  expanded_macro.each do |a_macro|
    # ...
  end
end

or

expansion.expanded_sources
  .zip(expansion.expanded_macros)
  .each_with_index do |(expanded_source, expanded_macro), j|
    expanded_macro.each do |a_macro|
      # ...
    end
  end

What I'm heading at is placement of .zip(expansion.expanded_macros), which in this case was IMO too far out (pun intended) ;)

Thinking about it again, I think @Sija's right.

I think that

expansion.expanded_sources.zip(expansion.expanded_macros)
                          .each_with_index do |(expanded_source, expanded_macro), j|
  expanded_macro.each do |a_macro|
    # ...
  end
end

should format to

expansion.expanded_sources.zip(expansion.expanded_macros)
    .each_with_index do |(expanded_source, expanded_macro), j|
      expanded_macro.each do |a_macro|
        # ...
      end
    end

personally (4 spaces to indent a method chain broken onto multiple lines).

I'd then be encouraged to do this, which I believe to be my favourite formatting:

expansion.expanded_sources
    .zip(expansion.expanded_macros)
    .each_with_index do |(expanded_source, expanded_macro), j|
      expanded_macro.each do |a_macro|
        # ...
      end
    end

I totally agree with @RX14's idea. Dot based alignment is painful. (and why align to last dot on previous line?)

@RX14 I'm totally fine with 4 spaces indentation for method chained dot-lines. Though I'm not sure if this needs to be enforced by the formatter.

@asterite Why does the formatter align method chain with the last dot on previous line? So, why the formatter keeps this:

foo.bar.baz
       .quz

This behavior makes too deep indentation and I think it is wrong. If the formatter aligns method chain with first dot, this PR fix does not lose readability in many case.

By now I think the formatter should always use 2 spaces to indent.

@asterite I agree normally, but I think that's wrong in the case of multi-line statements. Adding more indent makes it clear that it's a continuation of the previous statement, not just a normal control-flow indent.

I implemented @RX14's idea at fix/crystal-format/multiline-call-4-space-indent branch. And this is the diff to apply a new crystal tool format to crystal source tree. It looks totally good, especially these lines become quite good.

What do you think?

Opened a new pull request #5234.