We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I was reading the code of lines in connection to #3 and noticed that it only cares about \ns.
lines
\n
I call lines on the result of getContents, which requires binary mode. That in turn means that the automatic newline conversion won't be happening.
getContents
So, if I'm reading this right, the code will not work correctly on Windows, will it?
The text was updated successfully, but these errors were encountered:
FYI, I started working on this in my fork (as you can see above).
I'll let you know once I finish.
Sorry, something went wrong.
Sorry, I'm just getting to these. I was trying in these modules to replicate Data.ByteString.Lazy(.Char8) as much as possible. In bytestring, no account is taken of line endings other than \n it seems. http://hackage.haskell.org/package/bytestring-0.10.6.0/docs/src/Data.ByteString.Lazy.Char8.html#lines
Data.ByteString.Lazy(.Char8)
bytestring
Yes, I also noticed that. But I don't think we should regard that as a standard; see e.g. this stackoverflow discussion.
Another question is whether unlines should be changed, too... While the conversion in lines hardly has any downsides, it's much trickier with unlines.
unlines
No branches or pull requests
I was reading the code of
lines
in connection to #3 and noticed that it only cares about\n
s.I call
lines
on the result ofgetContents
, which requires binary mode. That in turn means that the automatic newline conversion won't be happening.So, if I'm reading this right, the code will not work correctly on Windows, will it?
The text was updated successfully, but these errors were encountered: