Indented lines with 4 or more spaces in list are interpreted as code blocks

[susisu]

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.

• https://spec.commonmark.org/0.29/#example-282
• https://github.github.com/gfm/#example-292

- 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.

[wooorm]

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).

I shared more of my thoughts about this issue here.