Allow disabling wrapping <p> tags in one liners.

Steps to reproduce the problem (provide example input)

Parser parser = Parser.builder().build()
HtmlRenderer renderer = HtmlRenderer.builder().build()
Node document = parser.parseReader('Here I have a test [link](http://www.google.com)')
String result = renderer.render(document)

Expected behavior:

result == "Here I have a test <a href="http://www.google.com">link</a>"

Actual behavior:

result == "<p>Here I have a test <a href="http://www.google.com">link</a></p>"

I understand that this may be a breaking change, so an option on HtmlRenderer on this would be sufficient.

[dustindclark]

Again, consumers should not be aware of or rely on any specific HTML or structure that is generated by this library. I’m not arguing that it isn’t easy…it is incredibly easy. However, it’s not future proof and it’s brittle. It also completely defeats the purpose of using any rendering library (MD or otherwise) to have to post process and manipulate the results. Think of it like a translator library. If I call you to translate English to Spanish, should I manipulate the output or ask you for a specific dialect? It’s no different for MD to HTML.

I’m not sure how else to explain that this is a bad design decision. Coding around it is almost as painful as having to explain why.

[robinst]

Are you saying that libraries/apps that consume CommonMark should be aware of the HTML/DOM that is being generated and manipulate it accordingly?

They have to be aware of the AST (abstract syntax tree, node structure), yeah.

That’s extremely brittle and breaks every time HtmlRenderer changes.

No, it doesn’t. To be clear, what I’m proposing is that you do this:

• Parse the text
• Manipulate the AST if needed
• Render it using HtmlRenderer

The middle step is not dependent on how HtmlRenderer behaves. Not sure why you would think that?

We could add a utility method for this middle step, but I’m not sure about it yet. The method name would be something like unwrapParagraphIfDocumentContainsSingleParagraph(Node document)

The problem here is that CommonMark makes a bad assumption that a single line is a paragraph in the first place.

It’s consistent with what the reference implementations commonmark.js and cmark do. I had a quick look and there’s an open issue for the JS implementation here, but no replies yet: https://github.com/commonmark/commonmark.js/issues/152