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

Question

在我使用的多个 Markdown 到 pdf 转换器中，当您有一个索引超过 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

Markdown syntax rules实际上并没有解释如何将列表项嵌套在其他列表项中。但是，它们确实演示了嵌套段落(还有 block 引用和代码块):

List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab:

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 中，这不是必需的。正如规则的下一段所述:

It looks nice if you indent every line of the subsequent paragraphs, but here again, Markdown will allow you to be lazy...

当然，当您的列表超过 99 个项目时，对齐良好的“列”不再适用于四个缩进空格:

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

但是，由于任何 block 级项目最多可以缩进三个空格(在不成为代码块的情况下，您可以在嵌套行中添加最多三个缩进空格:

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 的创建者希望强制执行格式良好的列，而不受 99999 的限制。项目，因此它们偏离了 Markdown 规则。 Commonmark 不需要四个缩进空格来嵌套一个项目，但根据它的 spec :

The most important thing to notice is that the position of the text after the list marker determines how much indentation is needed in subsequent blocks in the list item. If the list marker takes up two spaces, and there are three spaces between the list marker and the next non-whitespace character, then blocks must be indented five spaces in order to fall under the list item.

...

It is tempting to think of this in terms of columns: the continuation blocks must be indented at least to the column of the first non-whitespace character after the list marker. However, that is not quite right. The spaces after the list marker determine how much relative indentation is needed. Which column this indentation reaches will depend on how the list item is embedded in other constructions...

换句话说，Commonmark 需要在 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演示，在这种情况下，一些较新的非通用标记实现确实遵循通用标记。因此，根据您使用的 Markdown 实现，YMMV。