Indented lines with 4 or more spaces in list are interpreted as code blocks
susisu opened this issue · comments
Subject of the issue
I'm upgrading remark-parse
from 8.0.3 to 9.0.0 and using remark-gfm
.
I found that the following indented list items example from CommonMark / GFM specs yields a different result from the specs.
- a
- b
- c
- d
- e
I don't think the package should be 100% spec compliant, and I'm sorry if it's actually working as intended.
Your environment
- OS: macOS 10.15.7
- Packages:
unified@9.2.0
remark-pase@9.0.0
remark-gfm@1.0.0
remark-rehype@8.0.0
rehype-stringify@8.0.0
- Env:
- Node.js v12.14.0
- Yarn 1.22.5
- Chrome 87.0.4280.40
Steps to reproduce
See https://codesandbox.io/s/charming-dew-m14g7?file=/src/index.js
Expected behavior
As the specs say:
<ul>
<li>a</li>
<li>b</li>
<li>c</li>
<li>d
- e</li>
</ul>
Actual behavior
<ul>
<li>a</li>
<li>b</li>
<li>c</li>
<li>d</li>
</ul>
<pre><code>- e
</code></pre>
Without remark-gfm
, it works as expected.
The next example in the spec shows a result like this, but it's because there is a blank line before 3. c
.
This is a bug! Specifically, in micromark-extension-gfm-table
. A similar bug is also in remark-frontmatter
through micromark-extension-frontmatter
. It is something that isn’t present in normal markdown (commonmark), because there multiline blocks are defined by their first line, but for frontmatter the last line defines it, and for tables the second line (alignment row).