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

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.

@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"

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

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:

Can this not be fixed with an option setting?

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

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

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.

This is breaking our lists as well.

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

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

Seriously, something should be done.

@concatime This is an open source project, maintained by volunteers who put there free time into this.
Feel free to help with this issue or set a bounty on it.

Firstly, I've never stated otherwise.
Secondly, my comment was a way to up this thread, which was inactive (5 months).
That being said, I love this project, but I don't have the technical abilities to fix this issue.
Greet.

I've run into the same issue.

To resolve this issue, I've write a new markdown parser that get full compliance with CommonMark¹.

• goldmark

It seems that almost users here run into this issue via applications using blackfriday.
Consequently, my new markdown parser may not resolve your issues.
If you are an author of an application that uses blackfriday, my new markdown parser maybe do the job.

@yuin, is there any way for you to speak to the Hugo dev's to see if they could offer your library as an option?

@TotallyInformation I am not a Hugo user and do not know Huge well. So I am not suitable for making new issues on Hugo. Could not you make a new issue on gohugoio/hugo?

Hugo has already been used by so many users, so it may be hard that Hugo changes default markdown parser. But using goldmark as an optional markdown parser may be possible.

If you make a new issue on gohugoio/hugo, you should talk about CommonMark.
If Hugo developers think that Commonmark has advantages, goldmark may be a candidate of a new markdown parser.

Thanks. I will try to find some time. I've not been active there for a while since my setup pretty much just works with the exception of these niggles with the MD.

I would suggest it as an option rather than straight replacement as it clearly isn't a 1-2-1 replacement.

I've noticed this when using orgmode as well. Is there a maintainer that can point me in the right direction to fix?

I'm having issues with this at work, my coworkers are using standard markdown syntax for nested lists that is then not rendered correctly.

A switch to two spaces for indentation would be really helpful.

goldmark is now hugos markdown parser: https://gohugo.io/news/0.62.0-relnotes/

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

@dmitshur you mentioned that 4 is the default, but is it possible to change the default?
I looked in the code and couldn't find a way to do this. I see there is a TabSizeDefault = 4 constant but the only place where it is read I see that it is controlled by the TabSizeDouble flag, but I don't see any way to set it to 2 spaces on instantiation of the renderer.