Deep nested lists don't output correctly

[jdale88]

I've noticed this with both Hugo and Live Markdown, but deep nested lists don't produce the results I'd expect to see based on other Markdown parsers.

The following Markdown:

* Outer
  * Nested
    * Inner

Is output as:

• Outer
  ◦ Nested
  ◦ Inner

But I'd expect to see:

• Outer
  • Nested
    • Inner

[dmitshur]

I think it's a matter of configuration. By default, tabs are set to size of 4 spaces, not two.

Try using tab characters, or 4 spaces, and it renders as you'd expect.

* Outer
    * Nested
        * Inner

[jdale88]

Hmm, you're right... but it's really odd that it renders "Nested" correctly (which is only indented by '..' rather than '....'). I'd argue it should at least be consistent in its behaviour (although changing it to strictly observe the tab width configuration would probably break a lot of things).

I would have usually used tabs, and I only used spaces because some Markdown cheat sheet said that nested lists were indented with two spaces (probably because it's easier to do it a web-browser).

These things all render correctly, and they're all inconsistent...

* Outer
 * Nested
     * Inner

* Outer
  * Nested
     * Inner

* Outer
   * Nested
     * Inner

* Outer
    * Nested
     * Inner

It seems that any indentation greater than the previous depths tab-stop width causes it to indent. So:

• If your root level is tab-stop 0, then a single space makes a nested bullet indent.
• If your nested level is tab-stop 1, then a single space makes a sub-nested bullet indent (so 5 spaces, or 1 tab 1 space).

The GitHub markdown by comparison seems to have a tab-width of 2, but requires that nested bullets be a tab-width deeper than the preceding bullet level.

[richmahn]

@jdale88 https://daringfireball.net/projects/markdown/syntax#list Standard for lists...note the "List markers typically start at the left margin, but may be indented by up to three space"

[tarpdalton]

two spaces works in the commonmark spec:
http://spec.commonmark.org/0.28/#example-270

Also, markdown linter defaults to 2 spaces
https://github.com/DavidAnson/markdownlint/blob/v0.6.1/doc/Rules.md#md007

maybe blackfriday should switch to 2 spaces

[lloeki]

Try using tab characters, or 4 spaces, and it renders as you'd expect.

That workaround does not work and still produces wrongly nested lists.

This is annoying as linters such as markdownlint will both complain in VSCode and block CI for our documentation generator, but it fails to render correctly within GitLab and Hugo.

Here's a round-up using the exact same source for the record, using VSCode vs GitHub vs Mattermost vs GitLab vs Hugo:

[TotallyInformation]

Can this not be fixed with an option setting?

It is really frustrating when having to migrate from one platform to another.

[shadowimmage]

I would also like to share my opinion that this is annoying/frustrating. I just started with Hugo and I use Visual Studio Code with markdownlint and had to create a special setting override to set the tabsize for markdownlint to 4 instead of the default of 2.

.markdownlint.json

{
    "MD007": { "indent": 4 },
    "MD013": false
}

Having all the tabstops at 4 seems to be OK for nested lists so far.

Using Hugo version 0.40.2

[monkeyhybrid]

I'd also like to see support for 2 space indenting, or at least an option for it. I use Gitea, which uses Blackfriday for Markdown rendering, and when cloning projects from GitHub or importing Markdown from elsewhere, it's not unusual to be loved by anyone to see deep lists get messed up because of this. It makes Markdown less portable than it could be.

[DavidWells]

This is breaking our lists as well.

Would it be hard to update Blackfriday to how everything else works? (2 spaces)

[TotallyInformation]

This continues to be out of step with other markdown implementations and causes significant problems for Hugo when migrating from other implementations.

[concatime]

Seriously, something should be done.