tfausak/cabal-gild

Reconsider CRLF handling?

Closed this issue · 0 comments

Currently Gild will treat CRLF as LF when checking. This isn't explicitly documented anywhere, but there's a comment in the code:

-- The input might have CRLF ("\r\n", 0x0d 0x0a) line endings, but the
-- output will always have LF line endings. For the purposes of the check
-- command, we'll consider the input formatted if it only differs from
-- the output in line endings.

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|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.