some lines not wrapped to specified width

[CobaltCause]

Description

I want to use --width 80 but it seems to not actually matter what value I pass, in the below example, the output is always the input.

Small example input

{
  users.users.root.openssh.authorizedKeys.keyFiles = getAllOther "keyFiles" rootName;
}

Expected output

Should be formatted to wrap at 80 columns. I don't particularly care what exactly that would look like.

Actual output

The input is unmodified.

[piegamesde]

Let's set aside for now that the line length option in its current form has drifted pretty far away from its original semantic intention — You sound like you'd want a fairly hard line limit and code to never exceed that. If so, how would you want Nixfmt to deal with lines which inherently exceed that limit, like long comments and strings? Unlike in many other programming languages, this tends to happen pretty often in common Nix code, mostly due to hashes and source URLs.

[piegamesde]

In #256 I reintroduce the line break after the = which I'd previously removed, and in the Nixpkgs diff you can see why I removed it in the first place: In most of the cases, adding a line break only reduces the overall line width by a couple of characters, with the line still remaining over budget in most of the cases while just looking worse overall. However, I could reintroduce the line breaks again for the cases where the LHS is sufficiently long.

[CobaltCause]

You sound like you'd want a fairly hard line limit and code to never exceed that.

Yeah.

---

Oof, TIL Nix can't escape newlines in strings:

$ cat wat.nix
"lol \
lmao"
$ nix eval --file wat.nix --raw | od -t x1
0000000 6c 6f 6c 20 0a 6c 6d 61 6f
0000011

In other languages this would result in:

0000000 6c 6f 6c 20 6c 6d 61 6f
0000010

---

Generally I find that (nightly) rustfmt does what I want:

• There's an option to wrap text in comments (this obviously interacts badly with commented out code, but this works well for me since I don't commit commented out code, and is fine in general since it's optional behavior)
• Comment lines with URLs are left untouched so that they can be clickable (in the editor or terminal or whatever)
• Long string literals are wrapped by escaping the newline, but apparently Nix can't do this
• There's an option to exit nonzero and print errors if any lines can't be formatted under the specified width

---

this tends to happen pretty often in common Nix code, mostly due to hashes and source URLs.

I think probably the worst part is that automatically reflowing text in Nix code isn't straightforward because a lot of it is inline Bash. Even if the code still does the same thing it probably causes rebuilds since the literal text would be different.

In this case I would probably expect nixfmt to not attempt to reflow '' strings and exit nonzero if the line is too long and nixfmt was configured to exit nonzero on unformattable lines that are too long.

[piegamesde]

Oof, TIL Nix can't escape newlines in strings

Uh you not gonna like this, but Nix does have escaping rules, otherwise in your example the \ would be part of the string value. It's just that the semantics are borked: \ escapes every character as itself (except for r and n and "), so \f becomes f and \ newline becomes just newline.

[CobaltCause]

lmao