search

mity / md4c

C Markdown parser. Fast. SAX-like interface. Compliant to CommonMark specification.
MIT License
776 stars 146 forks source link

Extensions for Reddit flavor markdown #28

Open jimmyjxiao opened 6 years ago

jimmyjxiao commented 6 years ago

In particular, superscripts and subscripts like hoedown has, and auto linking of /r/ subreddits would be nice

mity commented 6 years ago

I know that there is some work on the reddit autolinks by @DemiMarie but IDK whether she considers it ready for merging.

About the superscripts and subscripts, the situation is more complicated. There are (at least) two competing syntax approaches.

One is represented by reddit and Hoedown, but note these do not support subscripts:

text^superscript
text^(superscript with space)

The other approach is represented by pandoc:

text^superscript^
text^superscript with space^
text~subscript~
text~subscript with space~
craigbarnes commented 6 years ago

@mity What do you think about definition lists as an extension? Would you have any objections if someone were to send a patch for it? In particular I mean the style that originated in PHP Markdown Extra that's supported by Pandoc, MultiMarkdown, etc:

Term 1

:   Definition 1

Term 2 with *inline markup*

:   Definition 2

        { some code, part of Definition 2 }
mity commented 6 years ago

What do you think about definition lists as an extension? ... In particular I mean the style that originated in PHP Markdown Extra that's supported by Pandoc, MultiMarkdown, etc:

Extensions for widely used features of popular parsers are IMHO good thing, and e.g. Pandoc surely falls in that category. Having eventually MD_DIALECT_PANDOC similar to MD_DIALECT_GITHUB would be great thing and implementing MD_FLAG_DEFLIST might be the 1st step in that direction.

In contrast, I would almost certainly refuse any extensions for syntax constructions not yet seen anywhere: I do not intend to maintain some experimental features with very unclear future.

Would you have any objections if someone were to send a patch for it?

Not at all, as long as:

DemiMarie commented 6 years ago

Also, can we ensure that the extension uses strictly linear time and is adequately fuzz tested?

On Nov 29, 2017 7:00 PM, "Martin Mitáš" notifications@github.com wrote:

What do you think about definition lists as an extension? ... In particular I mean the style that originated in PHP Markdown Extra that's supported by Pandoc, MultiMarkdown, etc:

Extensions for widely used features of popular parsers are IMHO good thing, and e.g. Pandoc surely falls in that category. Having eventually MD_DIALECT_PANDOC similar to MD_DIALECT_GITHUB would be great thing and implementing MD_FLAG_DEFLIST might be the 1st step in that direction.

In contrast, I would almost certainly refuse any extensions for syntax constructions not yet seen anywhere: I do not intend to maintain some experimental features with very unclear future.

Would you have any objections if someone were to send a patch for it?

Not at all, as long as:

  • the patch has reasonable code quality,
  • the patch adds a command line option to md2html to enable it,
  • the patch provides a reasonable set of unit tests covering it (see scripts/run-tests.sh and test subdir)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mity/md4c/issues/28#issuecomment-348037626, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB3_Ow_rgyzEL93T_rSLLJXPz0Ziiks5s7fAHgaJpZM4QjQ_V .

mity commented 6 years ago

Also, can we ensure that the extension uses strictly linear time

Yes, that's also required. I'll edit the previous post.

and is adequately fuzz tested?

This is hard to request from writer of the patch. Such requirement would imho discourage many potential contributors. And even if it would be requested, how can you measure what's adequate?

I have ready some infrastructure on my Linux box so I would do that if there is any patch ready for it.