You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Heya! Thanks for the wonderful parser, it's by far the best one I've used yet.
The only markdown elements which seem to be unparsable using CocoaMarkdown (besides tables, which would be pretty impossible to render without ASCII art anyway) are superscript.
Although I see that superscript HTML characters can be transformed into attributes using the CMHTMLSuperscriptTransformer class, there is no equivalent convenience for markdown. In fact, after running through the codebase for a while, it only makes sense to modify cmark itself to add this parsing ability... it's not a part of the delegate pattern or customization of CocoaMarkdown to add different markdown parsing tokens. This makes sense, but means that adding my necessary features to the markdown capability of CocoaMarkdown requires modifying an underlying library/framework (which ideally would be separable/detachable and not dependent; because CocoaMarkdown is already an extension on cmark, making an extension on the cmark that CocoaMarkdown uses would be inappropriate to upkeep (a fork inside a fork?!)).
Instead of diving that deep and modifying the C/C++ base itself, I wanted to create this issue so we could perhaps find a solution that involves CocoaMarkdown itself and extends the modular nature of the library (so perhaps other tokens can be added in the future, too). Although the delegate pattern is very convenient and useful, it does not seem appropriate for modifying parsing, only the attributes/effects of the parse-in-progress. Hope this is a reasonable request, cheers!
The text was updated successfully, but these errors were encountered:
@insanj Thanks for the feedback! I definitely agree that there should be an easier way to extend the parsing functionality without modifying the underlying cmark library. If cmark provided some way to hook into its parser to handle unrecognized tokens, it would be easy enough to implement support for it in CocoaMarkdown, but it doesn't seem like the cmark API allows for that.
I ran into the exact same use case you mentioned (superscripts) and ended up writing a hacky manual post-processing step that used regular expressions to find and handle superscript characters in the NSAttributedString created using CocoaMarkdown.
The only feasible solution I can think of would be to implement another parser in CocoaMarkdown that runs after cmark's own parser to provide support for Markdown syntax extensions. It would be a non-trivial effort that I currently don't have time to tackle, however.
Heya! Thanks for the wonderful parser, it's by far the best one I've used yet.
The only markdown elements which seem to be unparsable using CocoaMarkdown (besides tables, which would be pretty impossible to render without ASCII art anyway) are superscript.
Although I see that superscript HTML characters can be transformed into attributes using the CMHTMLSuperscriptTransformer class, there is no equivalent convenience for markdown. In fact, after running through the codebase for a while, it only makes sense to modify
cmark
itself to add this parsing ability... it's not a part of the delegate pattern or customization of CocoaMarkdown to add different markdown parsing tokens. This makes sense, but means that adding my necessary features to the markdown capability of CocoaMarkdown requires modifying an underlying library/framework (which ideally would be separable/detachable and not dependent; because CocoaMarkdown is already an extension on cmark, making an extension on the cmark that CocoaMarkdown uses would be inappropriate to upkeep (a fork inside a fork?!)).Instead of diving that deep and modifying the C/C++ base itself, I wanted to create this issue so we could perhaps find a solution that involves CocoaMarkdown itself and extends the modular nature of the library (so perhaps other tokens can be added in the future, too). Although the delegate pattern is very convenient and useful, it does not seem appropriate for modifying parsing, only the attributes/effects of the parse-in-progress. Hope this is a reasonable request, cheers!
The text was updated successfully, but these errors were encountered: