Markdown枚举列表,索引超过99,更改嵌套列表格式

Question

在我使用的pdf转换器的多个markdown中,当你有一个列表超过99的枚举列表时,项目上的任何嵌套列表都不再像我期望的那样格式化.

举个例子,

98. 98th element
    1. This is fine
99. 99th element
    - This looks okay
100. 100th element
    - This should not look like this
101. 101th element
    1. This is also broken

当转换为pdf成为,

作为一种解决方法,我知道您不必将正确的数字作为索引放在枚举列表中,但如果您这样做,则可以更轻松地编辑markdown文件.

我的问题是,上述行为是预期的还是我一直在使用的pdf转换器中的错误？

Answer 1

对于99以上的任何项目,您可能需要为嵌套项添加额外的缩进空间.请参阅下面的示例.

正确的行为和语法部分取决于您是使用旧式Markdown实现还是使用CommonMark实现.有关不同实现行为的比较,请参阅Babelmark.

降价

Markdown 语法规则实际上并未解释如何将列表项嵌套在其他列表项中.但是,它们确实展示了嵌套段落(也包括块引用和代码块):

列表项可能包含多个段落.列表项中的每个后续段落必须缩进4个空格或一个选项卡:

1.  This is a list item with two paragraphs. Lorem ipsum dolor
    sit amet, consectetuer adipiscing elit. Aliquam hendrerit
    mi posuere lectus.

    Vestibulum enim wisi, viverra nec, fringilla in, laoreet
    vitae, risus. Donec sit amet nisl. Aliquam semper ipsum
    sit amet velit.

2.  Suspendisse id sem consectetuer libero luctus adipiscing.

当然,如果您使用列表项而不是段落并以相同的方式缩进它,则会获得嵌套列表项.由于参考实现以这种方式工作,大多数老式克隆也以相同的方式工作.

最后,请注意在该示例中,列表项中所有段落的所有行都在左边缘排列.即使列表项的第一行在列表标记和段落的第一个单词之间有一个额外的空格.出于演示目的,以下是使用点替换空格的相同示例:

1.··This is a list item with two paragraphs. Lorem ipsum dolor
····sit amet, consectetuer adipiscing elit. Aliquam hendrerit
····mi posuere lectus.

····Vestibulum enim wisi, viverra nec, fringilla in, laoreet
····vitae, risus. Donec sit amet nisl. Aliquam semper ipsum
····sit amet velit.

2.··Suspendisse id sem consectetuer libero luctus adipiscing.

这使得格式很干净的文本.但是,在没有必要的老式降价中.正如规则的下一段所述:

如果你缩进后续段落的每一行,看起来很不错,但在这里,Markdown会让你变得懒惰......

当然,当您的列表超过99个项目时,精确对齐的"列"不再适用于四个缩进空格:

100.·This is a list item with two paragraphs. Lorem ipsum dolor
····sit amet, consectetuer adipiscing elit. Aliquam hendrerit
····mi posuere lectus.

但是,由于任何块级项目最多可以缩进三个空格(不会成为代码块,因此最多可以向嵌套行添加三个缩进空间:

100.·This is a list item with two paragraphs. Lorem ipsum dolor
·····sit amet, consectetuer adipiscing elit. Aliquam hendrerit
·····mi posuere lectus.

甚至:

10000.·This is a list item with two paragraphs. Lorem ipsum dolor
·······sit amet, consectetuer adipiscing elit. Aliquam hendrerit
·······mi posuere lectus.

当然,在Markdown中,这不是必需的,但确实看起来不错.一旦你超越99999它就不再有效,因为你会有太多的缩进,导致嵌套的项目成为代码块.

Commonmark

据我了解,Commonmark的创建者希望在没有99999项目限制的情况下强制执行格式良好的列,因此他们偏离了Markdown规则.Commonmark不需要四个缩进空间来嵌套项目,但根据其规范:

需要注意的最重要的事情是列表标记之后的文本位置确定列表项中后续块中需要多少缩进.如果列表标记占用两个空格,并且列表标记和下一个非空白字符之间有三个空格,则块必须缩进五个空格才能落在列表项下.

...

根据列来考虑这个是很诱人的:连续块必须至少缩进到列表标记之后的第一个非空白字符的列.但是,这不太对.列表标记之后的空格确定需要多少相对缩进.此缩进到达的列将取决于列表项在其他构造中的嵌入方式...

换句话说,在Markmark中需要在Markdown中具有良好的但不必要的格式以具有良好对齐的列.为了演示,考虑这个问题提供了缩进额外的空间用于物品的嵌套项目的例子100,并101(与空间点):

98.·98th element
····1.·This is fine
99.·99th element
····-·This looks okay
100.·100th element
·····-·This should not look like this
101.·101th element
·····1.·This is also broken

在项目中100并101注意项目的第一个字符如何与嵌套列表标记的第一个字符在同一列中对齐.根据Babelmark的说法,这适用于Markdown和Commonmark.

当然,两位数的项目和三位数的项目并不相互排列,但这没关系,因为每个项目都是独立计算的.但是,对于肛门保持,如果您愿意,可以在较低编号的项目中添加一些额外的缩进以进行完全对齐:

1.···First item
·····1.·Foo
98.··98th element
·····1.·This is fine
99.··99th element
·····-·This looks okay
100.·100th element
·····-·This should not look like this
101.·101th element
·····1.·This is also broken

正如Babelmark所展示的那样,在Markdown和Commonmark实现中获得了一致的结果.

如前所述,当你克服99999项目时,实现会再次发生分歧:

99999.·Foo

·······not a code block

100000.·Bar

········A code block in Markdown, but not in Commonmark.

而且,这可能是Commonmark具有替代行为的原因.虽然,正如Babelmark所示,在这种情况下,一些较新的非共同标记实现确实遵循Commonmark.因此,根据您使用的Markdown实施,YMMV.