Popular and needed extension


#1

I’d like to try to group the extension and who is needing them.

For my use-case, add markdown support to sphynx, I need a good deal of editorial support (e.g. include, attributes, yaml-extradata and few more) that probably can be implemented by adding the IAL support kramdown has or something similar, on top of it tables are of interest and maybe the math support.

I’m sure @vitaly knows more use-cases since he has a fairly large collection of plugins.


#2

I don’t track tendencies specially, but something can be analysed in https://www.npmjs.org/browse/keyword/markdown-it-plugin

My personal needs are:

  • math
  • some kinds of diagrams (not sure)
  • collapsible spoilers
  • quotes with ref to original & author (2 types - fenced and extension to current)
  • footnotes
  • tables
  • @mentions (github/twitter-like)

Other things i don’t need, but popular:

  • attributes (~ maruku-like syntax)
  • everything else, described in pandoc & php-markdown-extra extensions.

#3

Diagrams, spoilers, quotes, and mentions can easily be
handled using conventions with current syntax.
E.g. see the way gitit handles diagrams using fenced
code blocks: http://gitit.net/Dot%20Plugin%20Demo

But math, tables, and footnotes are things
that can’t be handled well without changes to the parser.
The priority now is still getting the core spec into shape
(that is hard enough), but I do envision that CommonMark
will eventually have some officially sanctioned extensions.


#4

As far as i remember, we already discussed situation with containers. I still stay, that usability of such containers depends on content height. blockquote is convenient for small height, and big height will be better with fenced-style blocks. I will implement both anyway for my needs.

From my point of view, the most affecting will be maruku-like attributes support. Because it will touch almost all elements. If this change is planned, it would be nice to have it sooner than later.


#5

For me, the priorities are:

All of these can implemented using either HTML or core-CommonMark syntax, but it would be nice to have humane, Markdown-esque syntax, as officially endorsed CommonMark extensions.