Markdown -> CommonMark extensions tracker

Markdown -> CommonMark extensions tracker

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2363 bytes --]

As pandoc moves toward commonmark_x as the default processor, I was 
thinking it might be nice to have a table of extensions and their current 
status with each processor, so users can see the status of the extensions 
they need, easing the decision of whether/when they can switch to using 
commonmark_x. Perhaps this could live on the GitHub wiki? 

I was imagining each extension could have one of several possible values, 
for markdown and for commonmark: 

- enabled by default
- disabled by default
- required by the spec (cannot be disabled)
- Not allowed by the spec (cannot be enabled)
- Not available (under development) 

and any other statuses that might be informative. I have put together a 
framework table from the result of pandoc --list-extensions, but that only 
lets me see whether they are disabled or enabled by default, or 
whether they do not appear as extensions (which could be for any of the 
latter three reasons). Rough vision: 

-----------------------------------------------------------------------------------
                                        commonmark             
markdown       
--------------------------------------- --------------------- 
---------------------
           **abbreviations**                     NA            disabled by 
default 

       **all_symbols_escapable**                 NA            enabled by 
default  

     **angle_brackets_escapable**                NA            disabled by 
default 

         **ascii_identifiers**           disabled by default   disabled by 
default 

            **attributes**               enabled by default            NA   
       

         **auto_identifiers**                    NA            enabled by 
default  

Would this be useful, and if so, could others more knowledgable than I help 
fill in the NAs with the other three possible values? I can post the 
framework table onto the Wiki if others will then help fill it in. 

Connor

-- 
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/11d4e07a-6151-42f1-8a2f-56ce4bb2ae1bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4324 bytes --]

Re: Markdown -> CommonMark extensions tracker

[John MacFarlane]

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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.

Re: Markdown -> CommonMark extensions tracker

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 3301 bytes --]

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 <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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-discuss+unsubscribe-/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.

[-- Attachment #1.2: Type: text/html, Size: 5972 bytes --]

Re: Markdown -> CommonMark extensions tracker

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 4565 bytes --]

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 <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org>
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 <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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-discuss+unsubscribe-/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
> <https://groups.google.com/d/msgid/pandoc-discuss/ec4a5de6-77a4-4a48-86cc-e3d2610f5257n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CADAJKhA3VdyosoGi%2BC_AjgK2hZLM%2B56ju8sHvd9yzMYqb%3D40QQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7601 bytes --]

Re: Markdown -> CommonMark extensions tracker

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 5585 bytes --]

--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 <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 
> 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 <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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 
>> <https://groups.google.com/d/msgid/pandoc-discuss/ec4a5de6-77a4-4a48-86cc-e3d2610f5257n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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.

[-- Attachment #1.2: Type: text/html, Size: 9149 bytes --]

Re: Markdown -> CommonMark extensions tracker

[John MacFarlane]

Note: at this point, we're talking about commonmark extensions
provided by pandoc. None of this is going into the commonmark
spec, which currently just focuses on the core. (Maybe at
some point.)

abbreviations - maybe?

all_symbols_escapable - this is already in core commonmark, so not an extension

angle_brackets_escapable - already in core commonmark

auto_identifiers - we have gfm_auto_identifiers, no plans to
support the old auto_identifiers, since I think it's best to
standardize on one system

backtick_code_blocks - part of core commonmark

blank_before_blockquote - incompatible with core commonmark,
won't be implemented as an extension

blank_before_header -  incompatible with core commonmark,
won't be implemented as an extension

citations - I plan to support this but it's not an easy one to implement

compact_definition_lists - I'd prefer not to support this, for
sake of standardization - it's here for legacy reasons

escaped_line_breaks - part of core commonmark

example_lists - plan to support

fenced_code_attributes - this is provided as part of the
attributes extension, don't plan to implement separately

fenced_code_blocks - part of core commonmark

four_space_rule - don't plan to implement, incompatible with core
commonmark

grid_tables - plan to implement, probably

gutenberg - this only really affects plain output

header_attributes - provided by attributes extension, don't plan
to implement separately

ignore_line_breaks - might make sense to implement, but this
would be a bit tricky to do as a commonmark-hs extension; we
might need a few changes to the core commonmark processor to
enable this.  I'd be curious how many people use it.

inline_code_attributes - provided by attributes, don't plan to
implement separately

inline_notes - will probably implement as an extension

intraword_underscores - part of core commonmark, won't be an extension

latex_macros - not sure, maybe

line_blocks - plan to implement as extensions

link_attributes - provided by attributes extension

lists_without_preceding_blankline - part of core commonmark,
don't plan to implement

literate_haskell - maybe

markdown_attribute - probably not, because commonmark has a
different way of doing this and I'd like to keep it simple

markdown_in_html_blocks - no, because commonmark has a different
way of doing this

mmd_header_identifiers - maybe

mmd_link_attributes - maybe

mmd_title_block - maybe

multiline_tables - plan to implement

native_divs - probably not; I'd prefer to just support the fenced divs

native_spans - ditto, bracketed_spans

old_dashes - probably not, a legacy feature

pandoc_title_block - probably?

shortcut_reference_links - part of core commonmark

simple_tables - plan to support

space_in_atx_header - part of core commonmark, won't be an extension

spaced_reference_links - incompatible with core spec, don't plan
to support

startnum - part of core commonmark

table_captions - plan to support but maybe as part of table extensions

tex_math_double_backslash - not sure; might support

tex_math_single_backslash - incompat with core commonmark
escaping, probably not

Re: Markdown -> CommonMark extensions tracker

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 4070 bytes --]

Great! I consolidated that down and added it as a table in the Roadmap page 
of the Wiki: https://github.com/jgm/pandoc/wiki/Roadmap. Please let me know 
if it would be better placed on a different page. I have set a reminder for 
myself to check it every month for updates. 

On Wednesday, July 21, 2021 at 11:53:15 AM UTC-7 John MacFarlane wrote:

>
> Note: at this point, we're talking about commonmark extensions
> provided by pandoc. None of this is going into the commonmark
> spec, which currently just focuses on the core. (Maybe at
> some point.)
>
> abbreviations - maybe?
>
> all_symbols_escapable - this is already in core commonmark, so not an 
> extension
>
> angle_brackets_escapable - already in core commonmark
>
> auto_identifiers - we have gfm_auto_identifiers, no plans to
> support the old auto_identifiers, since I think it's best to
> standardize on one system
>
> backtick_code_blocks - part of core commonmark
>
> blank_before_blockquote - incompatible with core commonmark,
> won't be implemented as an extension
>
> blank_before_header - incompatible with core commonmark,
> won't be implemented as an extension
>
> citations - I plan to support this but it's not an easy one to implement
>
> compact_definition_lists - I'd prefer not to support this, for
> sake of standardization - it's here for legacy reasons
>
> escaped_line_breaks - part of core commonmark
>
> example_lists - plan to support
>
> fenced_code_attributes - this is provided as part of the
> attributes extension, don't plan to implement separately
>
> fenced_code_blocks - part of core commonmark
>
> four_space_rule - don't plan to implement, incompatible with core
> commonmark
>
> grid_tables - plan to implement, probably
>
> gutenberg - this only really affects plain output
>
> header_attributes - provided by attributes extension, don't plan
> to implement separately
>
> ignore_line_breaks - might make sense to implement, but this
> would be a bit tricky to do as a commonmark-hs extension; we
> might need a few changes to the core commonmark processor to
> enable this. I'd be curious how many people use it.
>
> inline_code_attributes - provided by attributes, don't plan to
> implement separately
>
> inline_notes - will probably implement as an extension
>
> intraword_underscores - part of core commonmark, won't be an extension
>
> latex_macros - not sure, maybe
>
> line_blocks - plan to implement as extensions
>
> link_attributes - provided by attributes extension
>
> lists_without_preceding_blankline - part of core commonmark,
> don't plan to implement
>
> literate_haskell - maybe
>
> markdown_attribute - probably not, because commonmark has a
> different way of doing this and I'd like to keep it simple
>
> markdown_in_html_blocks - no, because commonmark has a different
> way of doing this
>
> mmd_header_identifiers - maybe
>
> mmd_link_attributes - maybe
>
> mmd_title_block - maybe
>
> multiline_tables - plan to implement
>
> native_divs - probably not; I'd prefer to just support the fenced divs
>
> native_spans - ditto, bracketed_spans
>
> old_dashes - probably not, a legacy feature
>
> pandoc_title_block - probably?
>
> shortcut_reference_links - part of core commonmark
>
> simple_tables - plan to support
>
> space_in_atx_header - part of core commonmark, won't be an extension
>
> spaced_reference_links - incompatible with core spec, don't plan
> to support
>
> startnum - part of core commonmark
>
> table_captions - plan to support but maybe as part of table extensions
>
> tex_math_double_backslash - not sure; might support
>
> tex_math_single_backslash - incompat with core commonmark
> escaping, probably not
>
>

-- 
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/abf704be-12e2-4952-98a1-4ca4660db027n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5035 bytes --]

Re: Markdown -> CommonMark extensions tracker

[John MacFarlane]

Great, thanks for this!

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:

> Great! I consolidated that down and added it as a table in the Roadmap page 
> of the Wiki: https://github.com/jgm/pandoc/wiki/Roadmap. Please let me know 
> if it would be better placed on a different page. I have set a reminder for 
> myself to check it every month for updates. 
>
> On Wednesday, July 21, 2021 at 11:53:15 AM UTC-7 John MacFarlane wrote:
>
>>
>> Note: at this point, we're talking about commonmark extensions
>> provided by pandoc. None of this is going into the commonmark
>> spec, which currently just focuses on the core. (Maybe at
>> some point.)
>>
>> abbreviations - maybe?
>>
>> all_symbols_escapable - this is already in core commonmark, so not an 
>> extension
>>
>> angle_brackets_escapable - already in core commonmark
>>
>> auto_identifiers - we have gfm_auto_identifiers, no plans to
>> support the old auto_identifiers, since I think it's best to
>> standardize on one system
>>
>> backtick_code_blocks - part of core commonmark
>>
>> blank_before_blockquote - incompatible with core commonmark,
>> won't be implemented as an extension
>>
>> blank_before_header - incompatible with core commonmark,
>> won't be implemented as an extension
>>
>> citations - I plan to support this but it's not an easy one to implement
>>
>> compact_definition_lists - I'd prefer not to support this, for
>> sake of standardization - it's here for legacy reasons
>>
>> escaped_line_breaks - part of core commonmark
>>
>> example_lists - plan to support
>>
>> fenced_code_attributes - this is provided as part of the
>> attributes extension, don't plan to implement separately
>>
>> fenced_code_blocks - part of core commonmark
>>
>> four_space_rule - don't plan to implement, incompatible with core
>> commonmark
>>
>> grid_tables - plan to implement, probably
>>
>> gutenberg - this only really affects plain output
>>
>> header_attributes - provided by attributes extension, don't plan
>> to implement separately
>>
>> ignore_line_breaks - might make sense to implement, but this
>> would be a bit tricky to do as a commonmark-hs extension; we
>> might need a few changes to the core commonmark processor to
>> enable this. I'd be curious how many people use it.
>>
>> inline_code_attributes - provided by attributes, don't plan to
>> implement separately
>>
>> inline_notes - will probably implement as an extension
>>
>> intraword_underscores - part of core commonmark, won't be an extension
>>
>> latex_macros - not sure, maybe
>>
>> line_blocks - plan to implement as extensions
>>
>> link_attributes - provided by attributes extension
>>
>> lists_without_preceding_blankline - part of core commonmark,
>> don't plan to implement
>>
>> literate_haskell - maybe
>>
>> markdown_attribute - probably not, because commonmark has a
>> different way of doing this and I'd like to keep it simple
>>
>> markdown_in_html_blocks - no, because commonmark has a different
>> way of doing this
>>
>> mmd_header_identifiers - maybe
>>
>> mmd_link_attributes - maybe
>>
>> mmd_title_block - maybe
>>
>> multiline_tables - plan to implement
>>
>> native_divs - probably not; I'd prefer to just support the fenced divs
>>
>> native_spans - ditto, bracketed_spans
>>
>> old_dashes - probably not, a legacy feature
>>
>> pandoc_title_block - probably?
>>
>> shortcut_reference_links - part of core commonmark
>>
>> simple_tables - plan to support
>>
>> space_in_atx_header - part of core commonmark, won't be an extension
>>
>> spaced_reference_links - incompatible with core spec, don't plan
>> to support
>>
>> startnum - part of core commonmark
>>
>> table_captions - plan to support but maybe as part of table extensions
>>
>> tex_math_double_backslash - not sure; might support
>>
>> tex_math_single_backslash - incompat with core commonmark
>> escaping, probably not
>>
>>
>
> -- 
> 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/abf704be-12e2-4952-98a1-4ca4660db027n%40googlegroups.com.

Re: Markdown -> CommonMark extensions tracker

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 5363 bytes --]

Will the newly added short_subsuperscript extension be added to commonmark_x 
at some point? Or is it just for markdown and markdown_mmd? (Also, in 
--list-extensions, it is the only extension that is not in alphabetical 
order. Not sure if that has to be manually sorted or what the deal is there)

On Thursday, July 22, 2021 at 11:43:29 AM UTC-7 John MacFarlane wrote:

> Great, thanks for this!
>
> Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:
>
> > Great! I consolidated that down and added it as a table in the Roadmap 
> page 
> > of the Wiki: https://github.com/jgm/pandoc/wiki/Roadmap. Please let me 
> know 
> > if it would be better placed on a different page. I have set a reminder 
> for 
> > myself to check it every month for updates. 
> >
> > On Wednesday, July 21, 2021 at 11:53:15 AM UTC-7 John MacFarlane wrote:
> >
> >>
> >> Note: at this point, we're talking about commonmark extensions
> >> provided by pandoc. None of this is going into the commonmark
> >> spec, which currently just focuses on the core. (Maybe at
> >> some point.)
> >>
> >> abbreviations - maybe?
> >>
> >> all_symbols_escapable - this is already in core commonmark, so not an 
> >> extension
> >>
> >> angle_brackets_escapable - already in core commonmark
> >>
> >> auto_identifiers - we have gfm_auto_identifiers, no plans to
> >> support the old auto_identifiers, since I think it's best to
> >> standardize on one system
> >>
> >> backtick_code_blocks - part of core commonmark
> >>
> >> blank_before_blockquote - incompatible with core commonmark,
> >> won't be implemented as an extension
> >>
> >> blank_before_header - incompatible with core commonmark,
> >> won't be implemented as an extension
> >>
> >> citations - I plan to support this but it's not an easy one to implement
> >>
> >> compact_definition_lists - I'd prefer not to support this, for
> >> sake of standardization - it's here for legacy reasons
> >>
> >> escaped_line_breaks - part of core commonmark
> >>
> >> example_lists - plan to support
> >>
> >> fenced_code_attributes - this is provided as part of the
> >> attributes extension, don't plan to implement separately
> >>
> >> fenced_code_blocks - part of core commonmark
> >>
> >> four_space_rule - don't plan to implement, incompatible with core
> >> commonmark
> >>
> >> grid_tables - plan to implement, probably
> >>
> >> gutenberg - this only really affects plain output
> >>
> >> header_attributes - provided by attributes extension, don't plan
> >> to implement separately
> >>
> >> ignore_line_breaks - might make sense to implement, but this
> >> would be a bit tricky to do as a commonmark-hs extension; we
> >> might need a few changes to the core commonmark processor to
> >> enable this. I'd be curious how many people use it.
> >>
> >> inline_code_attributes - provided by attributes, don't plan to
> >> implement separately
> >>
> >> inline_notes - will probably implement as an extension
> >>
> >> intraword_underscores - part of core commonmark, won't be an extension
> >>
> >> latex_macros - not sure, maybe
> >>
> >> line_blocks - plan to implement as extensions
> >>
> >> link_attributes - provided by attributes extension
> >>
> >> lists_without_preceding_blankline - part of core commonmark,
> >> don't plan to implement
> >>
> >> literate_haskell - maybe
> >>
> >> markdown_attribute - probably not, because commonmark has a
> >> different way of doing this and I'd like to keep it simple
> >>
> >> markdown_in_html_blocks - no, because commonmark has a different
> >> way of doing this
> >>
> >> mmd_header_identifiers - maybe
> >>
> >> mmd_link_attributes - maybe
> >>
> >> mmd_title_block - maybe
> >>
> >> multiline_tables - plan to implement
> >>
> >> native_divs - probably not; I'd prefer to just support the fenced divs
> >>
> >> native_spans - ditto, bracketed_spans
> >>
> >> old_dashes - probably not, a legacy feature
> >>
> >> pandoc_title_block - probably?
> >>
> >> shortcut_reference_links - part of core commonmark
> >>
> >> simple_tables - plan to support
> >>
> >> space_in_atx_header - part of core commonmark, won't be an extension
> >>
> >> spaced_reference_links - incompatible with core spec, don't plan
> >> to support
> >>
> >> startnum - part of core commonmark
> >>
> >> table_captions - plan to support but maybe as part of table extensions
> >>
> >> tex_math_double_backslash - not sure; might support
> >>
> >> tex_math_single_backslash - incompat with core commonmark
> >> escaping, probably not
> >>
> >>
> >
> > -- 
> > 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/abf704be-12e2-4952-98a1-4ca4660db027n%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/97ef942c-42de-413f-aacc-18792d3c9c6fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 7938 bytes --]

Re: Markdown -> CommonMark extensions tracker

[John MacFarlane]

I have no plans to add the extension to commonmark at this time.
But I did change it so in the future it will be in the correct order.

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:

> Will the newly added short_subsuperscript extension be added to commonmark_x 
> at some point? Or is it just for markdown and markdown_mmd? (Also, in 
> --list-extensions, it is the only extension that is not in alphabetical 
> order. Not sure if that has to be manually sorted or what the deal is there)
>
> On Thursday, July 22, 2021 at 11:43:29 AM UTC-7 John MacFarlane wrote:
>
>> Great, thanks for this!
>>
>> Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:
>>
>> > Great! I consolidated that down and added it as a table in the Roadmap 
>> page 
>> > of the Wiki: https://github.com/jgm/pandoc/wiki/Roadmap. Please let me 
>> know 
>> > if it would be better placed on a different page. I have set a reminder 
>> for 
>> > myself to check it every month for updates. 
>> >
>> > On Wednesday, July 21, 2021 at 11:53:15 AM UTC-7 John MacFarlane wrote:
>> >
>> >>
>> >> Note: at this point, we're talking about commonmark extensions
>> >> provided by pandoc. None of this is going into the commonmark
>> >> spec, which currently just focuses on the core. (Maybe at
>> >> some point.)
>> >>
>> >> abbreviations - maybe?
>> >>
>> >> all_symbols_escapable - this is already in core commonmark, so not an 
>> >> extension
>> >>
>> >> angle_brackets_escapable - already in core commonmark
>> >>
>> >> auto_identifiers - we have gfm_auto_identifiers, no plans to
>> >> support the old auto_identifiers, since I think it's best to
>> >> standardize on one system
>> >>
>> >> backtick_code_blocks - part of core commonmark
>> >>
>> >> blank_before_blockquote - incompatible with core commonmark,
>> >> won't be implemented as an extension
>> >>
>> >> blank_before_header - incompatible with core commonmark,
>> >> won't be implemented as an extension
>> >>
>> >> citations - I plan to support this but it's not an easy one to implement
>> >>
>> >> compact_definition_lists - I'd prefer not to support this, for
>> >> sake of standardization - it's here for legacy reasons
>> >>
>> >> escaped_line_breaks - part of core commonmark
>> >>
>> >> example_lists - plan to support
>> >>
>> >> fenced_code_attributes - this is provided as part of the
>> >> attributes extension, don't plan to implement separately
>> >>
>> >> fenced_code_blocks - part of core commonmark
>> >>
>> >> four_space_rule - don't plan to implement, incompatible with core
>> >> commonmark
>> >>
>> >> grid_tables - plan to implement, probably
>> >>
>> >> gutenberg - this only really affects plain output
>> >>
>> >> header_attributes - provided by attributes extension, don't plan
>> >> to implement separately
>> >>
>> >> ignore_line_breaks - might make sense to implement, but this
>> >> would be a bit tricky to do as a commonmark-hs extension; we
>> >> might need a few changes to the core commonmark processor to
>> >> enable this. I'd be curious how many people use it.
>> >>
>> >> inline_code_attributes - provided by attributes, don't plan to
>> >> implement separately
>> >>
>> >> inline_notes - will probably implement as an extension
>> >>
>> >> intraword_underscores - part of core commonmark, won't be an extension
>> >>
>> >> latex_macros - not sure, maybe
>> >>
>> >> line_blocks - plan to implement as extensions
>> >>
>> >> link_attributes - provided by attributes extension
>> >>
>> >> lists_without_preceding_blankline - part of core commonmark,
>> >> don't plan to implement
>> >>
>> >> literate_haskell - maybe
>> >>
>> >> markdown_attribute - probably not, because commonmark has a
>> >> different way of doing this and I'd like to keep it simple
>> >>
>> >> markdown_in_html_blocks - no, because commonmark has a different
>> >> way of doing this
>> >>
>> >> mmd_header_identifiers - maybe
>> >>
>> >> mmd_link_attributes - maybe
>> >>
>> >> mmd_title_block - maybe
>> >>
>> >> multiline_tables - plan to implement
>> >>
>> >> native_divs - probably not; I'd prefer to just support the fenced divs
>> >>
>> >> native_spans - ditto, bracketed_spans
>> >>
>> >> old_dashes - probably not, a legacy feature
>> >>
>> >> pandoc_title_block - probably?
>> >>
>> >> shortcut_reference_links - part of core commonmark
>> >>
>> >> simple_tables - plan to support
>> >>
>> >> space_in_atx_header - part of core commonmark, won't be an extension
>> >>
>> >> spaced_reference_links - incompatible with core spec, don't plan
>> >> to support
>> >>
>> >> startnum - part of core commonmark
>> >>
>> >> table_captions - plan to support but maybe as part of table extensions
>> >>
>> >> tex_math_double_backslash - not sure; might support
>> >>
>> >> tex_math_single_backslash - incompat with core commonmark
>> >> escaping, probably not
>> >>
>> >>
>> >
>> > -- 
>> > 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/abf704be-12e2-4952-98a1-4ca4660db027n%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/97ef942c-42de-413f-aacc-18792d3c9c6fn%40googlegroups.com.