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

Extensions for Reddit flavor markdown #28

Open
jimmyjxiao opened this issue Nov 19, 2017 · 5 comments
Open

Extensions for Reddit flavor markdown #28

jimmyjxiao opened this issue Nov 19, 2017 · 5 comments

Comments

@jimmyjxiao
Copy link

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

@mity
Copy link
Owner

mity commented Nov 19, 2017

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
Copy link
Contributor

craigbarnes commented Nov 29, 2017

@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
Copy link
Owner

mity commented Nov 30, 2017

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 algorithms involved have O(n) complexity in the worst case,
  • 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)

@DemiMarie
Copy link

DemiMarie commented Nov 30, 2017 via email

@mity
Copy link
Owner

mity commented Nov 30, 2017

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.

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

No branches or pull requests

4 participants