Should elm-format preserve CRLF line endings in files?

[avh4]

Apparently elm-format currently always converts files to LF line endings. I'm kinda surprised that I don't see any record of anyone noticing or complaining about this before -- if anyone has thoughts as to why that is, please comment below.

---

razzeee [] I build this (LSP elm-format wrapper) and it seems to work But there's one small annoyance where I'm not sure if it's Design or oversight elm-format always uses.. \n for newline even if it should be \r\n on windows for example

av [6:16 PM] oh, hmm, that’s interesting…. I’m surprised I don’t remember any windows users have ever reporting that as a bug before

razzeee [2:09 AM] git and your editor will mitigate this, but still operations on disk and unnessesary file changes

razzeee [2:24 AM] All elements with 0 are unchanged all with -1 mean remove. I'm diffing a local file with the return of elm-format fed via stdin. Pasted image at 2019-02-14, 11:24 AM

av [10:23 AM] ah, interesting. I’d be open to an elm-format PR to fix this — or having a github issue created to remind me to look at it sometime

razzeee [3:16 PM] Will do, just wanted to make sure it's not by design

razzeee [3:27 PM] this makes it seem like it is on purpose? https://github.com/avh4/elm-format/blob/master/tests/test-files/transform/WindowsEol.elm

av [5:26 PM]

elm-format converts all CRLF line-endings to LF.

ah, that was meant to mean “it currently does this”, not that there’s any reason it should I think I searched the past issues, and I don’t see any discussion about it, so maybe I just forgot, but I don’t see any reason why elm-format can’t keep the CRs — just that it doesn’t yet, and also it’s kinda interesting that no windows user has ever yet complained about it so yeah, I’m open to the change, but probably won’t be able to work on it myself for a while thanks for bringing it up!

razzeee [2:04 AM] will see if i can figure it out, but never did any haskell

av [10:30 AM] I would guess maybe a good approach would be, first figure out how in haskell we can even detect that CRLF is meant to be used instead of LF (I guess we’d want to determine that from the input file itself, since some windows users would be storing their Elm files with LF and others with CRLF, probably?) — and then maybe after that it might be as simple as having an option to Box.render that would join the lines with on vs the other. The complicated part might be in figuring out what edge cases to consider w/r to multiple string literals

[razzeee]

As far as I know windows editors will save with CRLF on default and most devs are probably using git to normalize line endings at their systems edge.

https://git-scm.com/docs/git-config#git-config-coreautocrlf

[buinauskas]

What @Razzeee has said. Default Git config will always normalize line endings in Windows. I've had no issues so far with this. :)

[erikhofer]

Maybe my configuration is wrong but I check out files with CRLF using git. If I then run elm-format from command line, files show up in git as modified because their line endings changed to LF (at least in WebStorm). I now added a .gitattributes with *.elm text eol=lf which works fine.

[harrysarson]

If I may chip in with my two cents. I use elm in windows subsystem for linux (wsl), using linux programs to read/write files in windows directories. (I promise this a legit work flow and one I believe will become much more common in the future). When possible I configure git/text editors to remove the CR character from all source files. In my experience windows programs can always handle files that only us LF[1] so there is no advantage for source files to contain the CR character.

My preference would be that CR characters are ignored by the elm compiler and removed by elm-format. If folk want to include CR characters (e.g. as part of a string) they must do so explicitly using an unicode escape (or \r if/when elm-format allows that). This is how it is at the moment.

--

CR = carriage return LF = line feed.

[1]: A notable exception is notepad on windows - what I suggest would be horrendous for anyone developing elm applications using notepad. I assume that no one does this though.

[harmboschloo]

I have a project with a travis-ci job for windows os. The job includes a elm-format --validate, but that currently fails because of the elm files being checkout with CRLF line endings. The probject also includes code that depends on proper os line endings, so I can't configures git's autocrlf differently.

Still have to figure out a proper workaround for this. But it would help if elm-format would generate os specific line endings. Or that --validate would ignore the line endings.