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

Question

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

举个例子，

{{1}}

转换为pdf后，

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

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

Answer 1

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

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

降价

Markdown syntax rules实际上并没有解释如何在其他列表项中嵌套列表项。但是，它们确实展示了嵌套段落（也包括块引用和代码块）：

  

列表项可能包含多个段落。每个后续段落中的一个   列表项必须用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个项目时，很好地对齐＆＃34;列＆＃34;不再使用四个缩进空格：

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不需要四个缩进空间来嵌套项目，但根据其spec：

  

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

     

...

     

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

换句话说，在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中，请注意项目的第一个字符如何与嵌套列表标记的第一个字符在同一列中对齐。根据{{​​3}}，这适用于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。