Markdown test fails with windows line endings in test file

[ihnorton]

unix2dos test/markdown.jl breaks the markdown test. This will be a problem for Windows people using editors that follow the platform convention, so we should try to be agnostic.

cc @one-more-minute @hayd

[hayd]

MD equality compares the html output, only one side includes \r\n here.

Note: Markdown.parse("\r\n #\r\n empty\r\n ") breaks terminal rendering, so I think this does need to be dealt with as if they are \n.

[MikeInnes]

Would it be enough to just strip out \rs completely? I imagine the spec has a lot to say about this kind of thing.

[hayd]

The spec says '\r' is a whitespace character (which we do, although we're missing \n and form feed) but (link):

A line ending is, depending on the platform, a newline (U+000A), carriage return (U+000D), or carriage return + newline.

I dislike the "depending on platform", to me it's reasonable to want all of these work (the same) regardless of platform.

This means you can't just strip the \rs!

Adding a util to eatnewline (to look for \r, \n and \r\n, and maybe eat it) shouldn't be that awkward a solution.... I'm not sure how invasive that will be in parsing logic. Will look into it.

---

Aside: readline doesn't work with just \r (unclear if that is a bug, or if it's "depending on platform"! :s).

[StefanKarpinski]

I agree that this shouldn't be platform dependent.

[hayd]

http://blog.codinghorror.com/the-great-newline-schism/

Had a little go, amusingly (asI mentioned it)... the annoying part, which makes this more complicated, does turn out to be that readline doesn't accept \r as a line ending! :s

[hayd]

Could the markdown text just go through a simple regex pass first:

replace(..., r"\r(\n)?", '\n')

[ihnorton]

related to #11988.