Tab-indented multiline-strings are turned into single-line strings

[infinisil]

Input (note that every line starts with a single tab character):

	''
	  foo
	  bar
	''

Expected output:

''
  foo
  bar
''

Actual output:

"  foo\n  bar\n"

This can be disastrous: https://gitlab.com/Fuzen-py/configsreborn/-/blob/2a6b5aa5c8bee37cc13ab35d186b8fa604f62b2c/Snow/homeManager/programs/waybar/default.nix#L93-96

[Lucus16]

This does indeed generate ugly output. The thing is, your suggested expected output changes the contents of the string (it removes the leading spaces). In fact, this string is impossible to format as indented strings without those leading tabs. Those tabs are a bit of a hack and I don't want to generate code like that. The proper solution could be to use concatStringsSep or concatMap to add the spaces to a list of lines or it could be to remove the leading spaces, but that's a decision that the programmer should make. Nixfmt should never change the semantics of the code on its own. Generating function calls is also tricky because we can't be sure whether lib or builtins is bound to what we expect. In the end it's best to leave it to the user to detect these cases and manually choose a solution.

PS. If you lost access to the unformatted indented string and feel it's a lot of work to recover the indented string, you could remove the indentation of any single line in the string and reformat again and nixfmt will turn it back into an indented string since it now has a valid representation as indented string.

[Lucus16]

I just checked nix repl and it seems Nix also includes the tabs as part of the string which means nixfmt is still changing semantics in this case. I'm considering making tabs in indentation a parse error.

[dasJ]

This changed (probably from @infinisil's new multiline string handling). It now returns a 4-space indented multiline string:

''
    foo
    bar
''

or

00000000: 2727 0a20 2020 2066 6f6f 0a20 2020 2062  ''.    foo.    b
00000010: 6172 0a27 270a                           ar.''.