Markdown Code Blocks Do Not Take Lists Into Account

[K4LCIFER]

I noticed the issue when I observed incorrect syntax highlighting for nested lists in markdown. I use Gruvbox for syntax highlighting, and while I was writing markdown, I noticed that after the 3rd nested item in a list (or 4 spaces), the line would end up being syntax highlighted (In the case of Gruvbox, it is highligted GruvboxAqua) for seemingly no reason. The same behaviour was observed if a list item was preceded by a tab. I found that in the code for Gruvbox, the color GruvboxAqua is referred to in conjunction with markdownCodeBlock. In vim-markdown, markdownCodeBlock was defined by the preceding whitespace of a line: specifically 1 tab or 4 spaces; however it does not take into account the edge-case that if the indented item is a list, it should not be treated as a markdownCodeBlock. As such, there should be a modification done that checks if the preceding indentation that would normally trigger a markdownCodeBlock is preceded by a list item: *, -, or +. If so, the following text should be treated as standard markdown text.

[strange]

Came here for this.

- A
    - B
        -C

-C is treated as a markdownCodeBlock.

Edit: NVIM v0.6.0-dev+153-g2cb8db34e

[tpope]

Patches welcome. But y'all maybe be greatly overestimating what is achievable with regexp based highlighting.

[strange]

No doubt about that. Merely reporting.

It works as expected with plasticboy/vim-markdown, maybe there's something there that is worth looking at?

[tpope]

That one appears to error on the side of list, while we error on the side of code block. That is, we handle this case correctly:

- list item
    -
        code

• list item

  code

[strange]

Doesn't Markdown require a blank line before the >=8-space indentation to identify the block as a code block?

The following works with plasticboy/vim-markdown and glow:

- list item
    - This is text

        code goes
        here

    - Another line

[tpope]

Doesn't Markdown require

There's no one spec, so there's no one answer. The example I shared works with GitHub Flavored Markdown.

But your assumption may indeed be a better default than the current behavior.

[strange]

But your assumption may indeed be a better default than the current behavior.

Requiring a blank line would make it easier to distinguish between line continuation and code blocks (for human consumers).

[artfulrobot]

I'd love a config option to ignore indents = code, as i find three backticks (ie codefences) clearer because indentation is difficult to manage.

[tpope]

I'd rather someone explore the blank line requirement. An option that disables indented code blocks would be an endorsement of code fences, which I don't want to do because code fences suck ass go against the spirit of Markdown.

[artfulrobot]

@tpope I feel your pain, though I do like code fences :stuck_out_tongue_closed_eyes: Like the point of Markdown is that it is readable, nay, beautiful and clear as plain text, yet that then causes problems when it's used in version control where diffs get huge if you add a word at the start of a para, leading people to specify no hard wrapping, breaking Markdown's glorious ideals, and then breaking even the layout when dealing with soft-wrapped indented lines :roll_eyes: