It would be awesome if we could add our own markdown.
For example, I like strikethrough, but it's not part of the CommonMark markdown spec, so I'd love to be able to add it. (Note: I don't want to allow HTML, so adding this would be a safer option)
~strike this~ ==> strike this
Agreed, would make a good addition. I've been wanting to replace the parser with something non-commonmark for a while, which would make this easier. Don't currently have time to implement it, but thanks for the suggestion. Will see if I get around to it at some point.
Double this, it will be a super nice feature. I use react-markdown in my personal blog service and I want to show "cuts" in the markdown preview:
>Read more< ==> <a href="fullPostUrl">Read more</a>
If you have no time, maybe we can help you a bit? I'm not very experienced developer, but I'd like to help.
Now that github is using CommonMark, do you still want to change the parser to something non-commonmark?
The commonmark parser we're using still doesn't support Github Flavored Markdown, even if Github Flavored Markdown is now based on it. If the commonmark parser supported GFM, I might reconsider, but I'm still thinking of switching.
Why not use https://www.npmjs.com/package/marked? It supports GFM since ages.
If plugins completed, is code coloring close in? 馃槅
Bumping for interest. I am using this package for a travel blog for me and the mrs and want to use markdown to make it easier for her to edit without writing actual html. I want to have different colours styles for when either me, or her, write something. For now I added a custom renderer for the inline code tag which takes: J:Hello and treats the J (or other letter) as the initial for our names and then add the appropriate react component to achieve the style I want. While this works, it's obviously not ideal, so some sort of plugin system would be fantastic.
Hmm, the demo page says it implements GFM, which seems to oppose what this thread says - might be worth updating :)
We support remark parser plugins now and have some basic building blocks for ast plugins as well. Closing.
Most helpful comment
Agreed, would make a good addition. I've been wanting to replace the parser with something non-commonmark for a while, which would make this easier. Don't currently have time to implement it, but thanks for the suggestion. Will see if I get around to it at some point.