--list-extensions can only tell you an extension is not available, it does not tell you *why*. If I have a document I was previously compiling using Pandoc's markdown plus some extensions, and I wanted to know if I can use the commonmark(_x) reader instead, --list-extensions=commonmark cannot answer that question. I will see only that an extension does not exist. I would then need to delve into the commonmark spec to infer whether it has been incorporated into core commonmark and thus is already available, or if the extension has yet to be developed for commonmark (but will eventually) and thus I need to wait for a later version of pandoc to make the switch. Obviously, people could just wait until commonmark_x becomes the default, but it would be useful to have that information compiled in one place. On Wednesday, July 21, 2021 at 11:00:14 AM UTC-7 BP wrote: > What would such a table/list achieve which is not already available, more > reliably since it is always up to date, with --list-extensions=FORMAT ? > > I guess one could write a script which takes a list of formats as input, > calls --list-extensions=FORMAT for each of them and assembles a pipe table > from the results. Providing such a script would arguably be more useful > than providing a static table which becomes out of date. > > > Den ons 21 juli 2021 19:42Connor Patrick Jackson > skrev: > >> re: not allowed by spec: Oh okay. I guess that only really makes sense >> for the handful of extensions that are allowed by commonmark but not by >> markdown, but that isn't really all that useful information. Are there any >> markdown extensions that, for whatever reason, will *never* be >> incorporated into commonmark, either within the spec or as an extension? >> That might be useful to know as well but there might not be any in that >> situation. >> >> Perhaps more useful would just be a list for each of the latter two >> categories: >> >> Former markdown packages that are permanently incorporated into the >> commonmark spec (this could be added to the manual rather than on the wiki, >> since it is essentially fixed, and would be a useful reference?) >> Markdown packages yet to be implemented in commonmark (this list belongs >> on the wiki as it gradually shrinks) >> >> I would happily volunteer to give myself a periodic calendar reminder and >> check in with pandoc --list-extensions and the release notes to see if >> any new extensions have been implemented, and update the Wiki list >> accordingly. If someone could put together the first list (I'm not super >> read-up on the details of the commonmark spec) I can put together the >> second. >> >> For convenience, the full list of markdown packages not available in >> commonmark (union of the two lists) as of 2.14.0.3 (and I don't believe >> 2.14.1 added any new commonmark extensions): >> abbreviations >> all_symbols_escapable >> angle_brackets_escapable >> auto_identifiers >> backtick_code_blocks >> blank_before_blockquote >> blank_before_header >> citations >> compact_definition_lists >> escaped_line_breaks >> example_lists >> fenced_code_attributes >> fenced_code_blocks >> four_space_rule >> grid_tables >> gutenberg >> header_attributes >> ignore_line_breaks >> inline_code_attributes >> inline_notes >> intraword_underscores >> latex_macros >> line_blocks >> link_attributes >> lists_without_preceding_blankline >> literate_haskell >> markdown_attribute >> markdown_in_html_blocks >> mmd_header_identifiers >> mmd_link_attributes >> mmd_title_block >> multiline_tables >> native_divs >> native_spans >> old_dashes >> pandoc_title_block >> shortcut_reference_links >> simple_tables >> space_in_atx_header >> spaced_reference_links >> startnum >> table_captions >> tex_math_double_backslash >> tex_math_single_backslash >> >> On Wednesday, July 21, 2021 at 10:17:45 AM UTC-7 John MacFarlane wrote: >> >>> Connor Patrick Jackson writes: >>> >>> > - Not allowed by the spec (cannot be enabled) >>> >>> This one doesn't really apply. Officially, the spec fully >>> specifies behavior, so no extension is "allowed by the spec." >>> >>> But it might be useful to distinguish between: >>> >>> > - required by the spec (cannot be disabled) >>> > - Not available (under development) >>> >>> If you have specific questions regarding this, I'd be >>> happy to answer. A table may be useful, but of course >>> there's the danger that it will become out of date and >>> thus misleading. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "pandoc-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/pandoc-discuss/ec4a5de6-77a4-4a48-86cc-e3d2610f5257n%40googlegroups.com >> >> . >> > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/d1d1e4ab-26c6-467b-9a61-40acdfc03aa8n%40googlegroups.com.