MD007 breaks on correct 2nd layer unordered list indentation

[dvzrv]

Hi! 👋

I'm using mado in some of my projects and noticed, that it seems broken around the validation of MD007.
When choosing e.g. indent to be 4, multiples of 4 are considered wrong.
When choosing indent to be 3 (the default according to the rule), multiples of 3 only some multiples of 3 are considered to be correct.

With the following configuration:

# ..
[lint.md007]
indent = 4
# ..

This works (but baz is then not rendered in e.g. mdbook as a subsubitem):

- foo
    - bar (4 spaces)
          - baz (10 spaces)

But this does not work (however, this renders correctly in mdbook):

- foo
    - bar (4 spaces)
        - baz (8 spaces)

When using the following configuration (which should reflect the defaults for MD007), the behavior of multiples of indent also does not work as expected:

# ..
[lint.md007]
indent = 3
# ..

This works:

- foo
   - bar (3 spaces)
         - baz (9 spaces)

This does not work:

- foo
   - bar (3 spaces)
      - baz (6 spaces)

However, when the mado.toml does not contain a specific [lint.md007] section, the default appears to not be indent = 3, as a consecutive indentation (and multiple) of 3 is considered an error.

[dvzrv]

I've adjusted my initial ticket text, as the default of 3 spaces is also broken.
In general this appears to be a problem with unordered lists that have items in the 2nd layer (or deeper).

[akiomik]

Thank you for reporting! I'll try to fix this.

[akiomik]

Thanks for the detailed report. I tried to reproduce this on the current main (comrak 0.46.0), and I couldn't get the false positive to show up.

Tested cases from this issue:

• indent = 4 with - foo\n - bar (4 spaces)\n - baz (8 spaces)\n → no MD007 violation
• indent = 3 with - foo\n - bar (3 spaces)\n - baz (6 spaces)\n → no MD007 violation
• 3-level nesting with indent = 4 → no MD007 violation
• Two sibling top-level items, each with a 2-level nested list (the shape in the original report) → no MD007 violation

These all match the existing check_no_errors / check_errors_for_multiple_indentation unit tests in src/rule/md007.rs, which already cover this exact shape and pass.

Could you share the exact markdown file and mado.toml that triggered the false positive? In particular, tabs vs. spaces, blank lines between items, or blockquote/ordered-list mixing might matter. I'll keep this open pending more repro details.

[dvzrv]

I'm a bit short on time currently.

You could try the commit before this one: archlinux/alpm@89fd5bb

[akiomik]

Thanks for the pointer. I checked out archlinux/alpm at the commit right before MD007 was disabled (88c3d658), which still has:

[lint.md007]
indent = 4

and ran it against three separate mado builds:

• comrak 0.40.0 (the version pinned in mado around when this issue was filed, 2025-08-14)
• comrak 0.46.0
• comrak 0.54.0 (current main, commit 76e89d6)

All three report All checks passed! on the whole alpm repo with its own mado.toml — no MD007 violations. I also re-ran the minimal repro cases from this issue (indent=4 and indent=3, 2-level and 3-level nesting) against all three builds; none trigger a false positive.

The MD007 rule logic hasn't changed since Dec 2024, and it doesn't reproduce on the comrak version contemporaneous with your report either, so I don't think this was a comrak-version-dependent fix — my test cases likely just aren't hitting whatever triggers it for you. Could you share the exact .md file (or the smallest snippet) that still fails, including whitespace/tabs as-is? A curl-able raw file or a code block with visible whitespace would help me match your case exactly.

[akiomik]

Possible lead while investigating #366: MD007 does produce a reproducible false positive on lists inside blockquotes, because md007.rs:51-54 computes indent as position.start.column - 1 without subtracting the blockquote prefix.

> * Foo
> * Bar

mado reports two MD007 violations; markdownlint reports none.

This does not explain your case directly — the archlinux/alpm tree checked clean in #190 (comment) — but if any of your affected files had bulleted lists inside blockquotes, that would be the shape to look for. Tracked in #367.