Newlines appended to conversions

[ruffin--]

If I have a file that contains only the characters and (so literally 61 6e 64 hex) and I convert to Markdown (using both CommonMark.CommonMarkConverter.Convert and the CommonMark.Console app with that binary in a file called test.md and a command line of CommonMark.Console.exe test.md --out out.html), I receive the following output:

3c 70 3e 61 6e 64 3c 2f 70 3e 0d 0a 0d 0a
aka
<p>and</p>\r\n\r\n

I'd expect:

3c 70 3e 61 6e 64 3c 2f 70 3e
that is,
<p>and</p>

without newlines.

[Knagis]

One \r\n should be there (the parser implies a newline in the source even if there is none), however the second one might be a bug. I will see if the second one can be removed.

[ruffin--]

Yep, just checked try.commonmark.org, and the JavaScript reference implementation does add a new line. When textarea.val() is "and", the result is "<p>and</p>\n". Okay, actually it's '<p data-sourcepos="1:1-1:3">and</p>\n', but that's beside the point.

Pain point -- I'm inserting a preprocessor for Multimarkdown tables and MarkUpDown multiline tables, and if I convert each cell's contents "on their own" so that they can contain Markdown, I get that extra newline, which makes the resulting table code parser unfriendly if there's whitespace and an empty line, but a Trim() with each convert is easy enough.

Thanks! Glad there was at least one valid improvement from the issue report!