Skip to content
New issue

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

support CommonMark? #53

Open
3b opened this issue Jan 27, 2023 · 0 comments
Open

support CommonMark? #53

3b opened this issue Jan 27, 2023 · 0 comments

Comments

@3b
Copy link
Owner

3b commented Jan 27, 2023

3bmd is older than CommonMark, so it tries to implement the original markdown syntax with reference to behavior of other markdown processors where that was ambiguous. That strategy has all the problems that motivated CommonMark, and CommonMark seems popular enough now that not matching it is annoying and/or confusing to users (ex #45).

Unfortunately, it looks like it would be difficult or impossible to write a proper PEG/TDPL grammar for the entire CommonMark spec at once, so it would probably be hard to maintain compatibility with existing 3bmd extensions.

It probably wouldn't be too hard to write a new parser using something like the multiple pass lines -> blocks -> inlines strategy suggested by the spec. The inlines pass might be able to reuse a lot of the 3bmd inline grammar, possibly with some limitations on length of code span delimiters and similar. In that case, inline extensions might be usable without too much changes (I'd probably want to clean up the AST in the process though, so they would need updates to match that). Block elements would need rewritten though, not sure if that pass would use esrap for parsing or if it would need something more complicated to handle the arbitrary indentation in lists/blockquotes. Possibly a hybrid with an esrap rule to detect start of a block, and then let the block parse the following lines however it wants.

I don't have any current plans to work on such a thing though, since my current limited markdown needs are satisfied by 3bmd as it is and I have other things that are higher priority for now (unless someone has a pile of money to throw at a commonmark parser or something). It does seem interesting enough that I might try to at least do a proof-of-concept between other projects at some point, but will probably be a while if so.


some related links:
CommonDoc : probable replacement for the ad-hoc AST in 3bmd in a rewrite
commondoc-markdown : Project using 3bmd with CommonDoc, possibly supporting CommonMark in the future.
cl-cmark : CommonMark processor using FFI to libcmark

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant