Always expand attrs

[infinisil]

Note

Closed in favor of #224

This implements this part of the standard:

nixfmt/standard.md

Lines 1259 to 1267 in f09ce41

	- Attribute set values must always be expanded. This has the consequence of always forcing nested attribute sets to be multiline (even if they would be single line otherwise because they only contain a single item), which usually is desired.
	```nix
	{
	foo.bar.baz = "qux";
	foo' = {
	bar.baz = "qux";
	};
	}
	```

This inconsistency was noticed in NixOS/nixpkgs#326430 (comment)

Edit: Though there's also this here:

nixfmt/standard.md

Line 1149 in f09ce41

- Lists and attribute sets can only be on a single line if they fit on the line and contain few enough items.

[github-actions]

Nixpkgs diff

[infinisil]

As a better alternative to this, I think we should finally implement input-aware formatting of lists/sets. Specifically to never contract lists/sets that are expanded onto multiple lines already.

We previously added this to the standard to make that possible:

nixfmt/standard.md

Line 67 in f09ce41

- The formatter may take the input formatting into account in some cases in order to preserve multi-line syntax elements (which would otherwise have been contracted by the rules).

[0x4A6F]

Thanks

[piegamesde]

The part of the standard you quote is taken out of context, this is a deliberate special case for bindings. IMO this sweeping approach of always expanding attributes is a net negative to the output layout, especially when attribute sets are non-last arguments to function calls.

Moreover, this misses several other similar inconsistencies which happen with lists.

The current rules have already been tweaked a lot, and I would strongly prefer an approach which refines them a bit more:

• Use prettyTermWide in prettyApp in contexts where prettyTermWide is already used (e.g. bindings)
• Expand the logic to also apply let binding bodies, in operator chains(?), and for lists

[infinisil]

Implemented the above alternative here: #224

[infinisil]

Closing in favor of the above alternative