I still feel like what Gild does is reasonable. On Windows, you're likely to end up with CRLF line endings one way or another. They don't change the semantics of the package description, so if it's otherwise formatted I think it's alright to pretend it has LF instead.
However, it might be nice to expose this as an option. That way you could get the default lenient behavior for the common case, but also opt in to strict behavior if you want to be pedantic. I'm thinking something like a --crlf=lenient|strict option that only applies for --mode=check.
Doing this would also have the knock on effect of actually documenting this behavior. So that's nice.
Currently Gild will treat CRLF as LF when checking. This isn't explicitly documented anywhere, but there's a comment in the code:
https://github.com/tfausak/cabal-gild/blob/747550fb20c4ab4003a199ebacd07130ce16796c/source/library/CabalGild/Main.hs#L92-L95
See also #12.
I feel like this is reasonable, but I was recently looking at Ormolu and they have a big scary warning about CRLF:
https://github.com/tweag/ormolu/blob/7e000cb1f62e8a713e424f8f354288053c7e39e8/README.md#zap-beware-gits-coreautocrlf-on-windows-zap
I still feel like what Gild does is reasonable. On Windows, you're likely to end up with CRLF line endings one way or another. They don't change the semantics of the package description, so if it's otherwise formatted I think it's alright to pretend it has LF instead.
However, it might be nice to expose this as an option. That way you could get the default lenient behavior for the common case, but also opt in to strict behavior if you want to be pedantic. I'm thinking something like a
--crlf=lenient|strictoption that only applies for--mode=check.Doing this would also have the knock on effect of actually documenting this behavior. So that's nice.