nixfmt icon indicating copy to clipboard operation
nixfmt copied to clipboard

Formatting of selections in function arguments does not agree with RFC 166

Open oxalica opened this issue 8 months ago • 0 comments

Description

Related: #153

I'm trying to apply RFC 166 style on rust-overlay and noticed this weird formatting.

Small example input

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; }).rustc stable."1.48.0".rustc;
}

Expected output

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; }).rustc
    stable."1.48.0".rustc;
}

Actual output

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; })
    .rustc stable."1.48.0".rustc;
}

It splits the selection in the first argument, but does not put the second arguments on a newline, which is really confusing to me. It looks like (assertEq (..)).rustc instead of assertEq ((..).rustc)

Rationale

As described in RFC 166:

Function application

  • In a function application chain, the first element is treated as the "function" and the remaining ones as "arguments".
  • As many arguments as possible must be fit onto the first line.
  • If there is at most one multi-line argument that can be absorbed and all other arguments before/after fit onto a single line respectively, then that multi-line argument is absorbed.

Thus the first argument should be inlined as a whole, and the second argument should be put on a new line (otherwise it would exceed the max width 100).

oxalica avatar Jun 23 '24 14:06 oxalica