Elm-format: multiline strings should not have EOL characters inserted on Windows

[avh4]

[avh4]

See http://stackoverflow.com/questions/6837628/data-bytestring-lazy-char8-newline-conversion-on-windows-is-the-documentation

[avh4]

@rtfeldman @jvoigtlaender As shown in the screenshot, back in December I was able to run the test script (a shell script) in Windows. But now I can't remember how I did that. Any ideas?

[jvoigtlaender]

Probably you have cygwin or mgwin or msys on your Windows machine, maybe even without having it installed consciously. It could have come with the Git or GHC installation. For example, if I drop down to a Git shell from the GitHub desktop application, I happen to be in an environment where I can call bash, whereas in a normal Windows shell I am not.

[avh4]

It was suggested that all ByteString usages should be changed to Text.

[avh4]

It turns out that the CRs were coming from the git checkout autoconverting the newlines in the example files. So it seems that the reading and writing of files is correct.

The remaining question is whether CRs (\x0D) should be escaped on Windows.

[diegonc]

tl;dr - I'd say no, they shouldn't

For easing interoperability Git has the core.autocrlf[1] setting, which is usually suggested to be set to true[2] on Windows machines.

The setting allows a developer's editor and tools to work with the native line endings while instructing Git to ensure a standardized line ending (LF) is always checked in. In that way all developers contributing to a Git repository will get the correct line endings for their system on checkout.

I ran a little test with elm-format-0.17 0.5.2-alpha using the following (already formatted) file:

module Main exposing (..)


a =
    """a
"""

composed under Windows using native line endings. So, this is how it actually looks in a hex-editor:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  6D 6F 64 75 6C 65 20 4D 61 69 6E 20 65 78 70 6F  module Main expo
00000010  73 69 6E 67 20 28 2E 2E 29 0D 0A 0D 0A 0D 0A 61  sing (..)......a
00000020  20 3D 0D 0A 20 20 20 20 22 22 22 61 0D 0A 22 22   =..    """a..""
00000030  22 0D 0A                                         "..

After running it through elm-format the file is transformed to use LF as a line terminator and the carriage return inside multi-line strings get escaped, as shown below.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  6D 6F 64 75 6C 65 20 4D 61 69 6E 20 65 78 70 6F  module Main expo
00000010  73 69 6E 67 20 28 2E 2E 29 0A 0A 0A 61 20 3D 0A  sing (..)...a =.
00000020  20 20 20 20 22 22 22 61 5C 78 30 44 0A 22 22 22      """a\x0D."""
00000030  0A                                               .

So, say some developer A who is using a Windows environment decides to commit and push the formatted file. Now when developer B, also using Windows (with the suggested Git configuration), clones the repository the checked out file would look like:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  6D 6F 64 75 6C 65 20 4D 61 69 6E 20 65 78 70 6F  module Main expo
00000010  73 69 6E 67 20 28 2E 2E 29 0D 0A 0D 0A 0D 0A 61  sing (..)......a
00000020  20 3D 0D 0A 20 20 20 20 22 22 22 61 5C 78 30 44   =..    """a\x0D
00000030  0D 0A 22 22 22 0D 0A                             .."""..

Sorry about all the hexed stuff 😄. There's two points here:

• Escaping the carriage return produces a corrupted string
• elm-format doesn't use native line endings

The latter is not a big problem as it can be fixed by Git. But the first point makes it impossible to work with multi-line strings under Windows[3].

---

[1] https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration#idp31554304

[2] https://help.github.com/articles/dealing-with-line-endings/

[3] Editors could be configured to work with LF only, granted

[avh4]

@diegonc thanks for the great write-up!

This is now fixed in eecc9771...a7e2ad66