commonmark
commonmark copied to clipboard
thephpleague
Support pretty printing Markdown
Description
Support pretty printing (beautifying) markdown content.
Example
In my use case, I am using Blade to render a Markdown file, comments in said Blade file render as blank lines (and other issues), and as such results in loosely formatted Markdown.
Being able to beautify Markdown would basically require us to parse the Markdown to an AST and then render it back out to Markdown instead of HTML. (And if we did that, we'd be halfway towards creating an HTML-to-Markdown converter which would replace https://github.com/thephpleague/html-to-markdown - something I would like to eventually do)
Unfortunately, I don't see this as something we'll be implementing in v1 (and not on the current roadmap for v2), but I do like this idea so I'll keep this open for now :)
Thanks for the suggestion!
I need to translate md documents via a translation API. It would be great to translate the text nodes and rebuild the document with a markdown renderer.
I need to translate md documents via a translation API. It would be great to translate the text nodes and rebuild the document with a markdown renderer.
You can, theoretically, already do this by listening for a DocumentParsedEvent event and then walking over the document and looking for Text nodes.
This issue is more about rendering the AST (after its been parsed) back into CommonMark.
Yes, I'm talking about AST. The task of automatically changing the markdown document (translation into another language, in my case, but not limited to it) is solved by parsing into AST tree, then processing the nodes in some way, and rendering back to the markdown.
I just wanted to further emphasize the importance of this issue. Because adds flexibility to the library and uses are limited only by imagination. I apologize if I was initially incomprehensible.
I've successfully created a very basic proof-of-concept (with minimal changes to the existing parsing/rendering logic) that converts Markdown -> AST -> Markdown with ~98% accuracy in my limited tests. There are some bugs though, and plenty of edge cases I haven't even attempted to explore yet, but my approach seems promising. If all goes well I might be able to bundle this in with #511 and #431 since they have similar implementation requirements.
Don't hold your breath yet, as I don't have enough confidence to determine whether this can drop in 2.0 or needs to wait for 3.0, but we'll see what happens :crossed_fingers:
