Open FranklinYu opened 7 years ago
I'm adding this for the reference of the alternatives. https://github.com/markdown/markdown.github.com/wiki/Implementations
I would be very interested to see Macdown fully support commonmark - especially the handling of <div>
blocks with markdown inside.
I added the +1 to @ijmitch's comment above, but I also wonder how many other users are using Macdown to author content for sites that do not fully support CommonMark, such as GitHub. I've been following CommonMark with bated breath for well over a year now, but I'm disappointed to see it apparently limited to content created and consumed within the same app/platform. I'd be interested in @franklinyu's and others' thoughts on this.
@jdickey Yes, the popularity of CommonMark is far from ideal. Currently my work-around is to use only the intersection of the behaviors. However, for MacDown, it has to choose a behavior; for example, GitHub Flavored Markdown is also a behavior (though perhaps not well-defined). What we can do right now is to choose one particular behavior before we cross our fingers and wait.
Among the available behaviors, I prefer CommonMark not because it's overwhelmingly popular (no one is, as far as I know), but because at least it's well-defined (or it tries to be well-defined).
It's sad, so sad It's a sad, sad situation
--Sorry Seems To Be The Hardest Word, Elton John
The main thing stopping MacDown adopting CommonMark is the feature set. Unfortunately parsers other than Hoedown generally either lack a lot of non-standard (but popular) features, or don’t offer a good way for lib users to extend the parser, including all popular CommonMark parsers I looked into.
Please let me know, anyone, if you can find (or build!) a Markdown parser that suits the need! Anything in C, C++, anything that can compiles to a C-compatible library would be ideal. JavaScript is possible if it can be run with JavaScriptCore.
Besides Remarkable mentioned in #723, markdown-it is another option.
Currently we are using master branch of Hoedown, which has a lot of bugs. There are (at least) two better alternatives:
However, neither is accessible through CocoaPods; I am not sure how to link a Git submodule.
Note that CMake is required as a compile-time dependency. I think it's fine for @uranusjr to install CMake (or he may have already), and Travis CI has CMake by default.