Closed lostenderman closed 1 year ago
The corresponding unit test is testfiles/CommonMark_0.30/lists/005.test
:
% ---RESULT--- "example": 305,
%
% <p>The number of windows in my house is</p>
% <ol>
% <li>The number of doors is 6.</li>
% </ol>
%
% ---\RESULT---
<<<
The number of windows in my house is
1. The number of doors is 6.
>>>
documentBegin
interblockSeparator
olBeginTight
olItemWithNumber: 1
olItemEnd
olEndTight
documentEnd
Here is the result of running git checkout commonmark; cd tests; ./test.sh "testfiles/CommonMark_0.30/lists/005.test"
:
Testfile testfiles/CommonMark_0.30/lists/005.test
Format templates/plain/
Template templates/plain/input.tex.m4
Command pdftex --shell-escape --interaction=nonstopmode test.tex
*** test-expected.log 2022-12-22 11:48:55.739015156 +0100
--- test-actual.log 2022-12-22 11:49:02.378957086 +0100
***************
*** 1,7 ****
documentBegin
- interblockSeparator
- olBeginTight
- olItemWithNumber: 1
- olItemEnd
- olEndTight
documentEnd
--- 1,2 ----
The issue seems related to the PEG patterns for parsing lists (1, 2), which use the rules for Gruber's Markdown, rather than CommonMark.
Similarly to options blankBeforeBlockquote
, blankBeforeCodeFence
, blankBeforeDivFence
, and blankBeforeHeading
, we should add option blankBeforeList
with default value of false
, which would control this behavior. See also https://github.com/Witiko/markdown/issues/29.
See https://spec.commonmark.org/0.30/#example-305 Follows #70