Fix list indentation

[hukkin]

Fix Markdown list indentation so that the lists are rendered as expected.

BTW, these errors were made obvious while I was testing a Markdown formatter I've been working on against this repository. The formatter could be a good match for this repository, being able to format Markdown tables, create/remove word wrap if desired, generate table of contents, format embedded code blocks (Python with Black) etc. I could set up a PR to showcase if this is something of interest to you?

[ralexstokes]

thanks for the PR! left some comments

[ralexstokes]

i think the formatting change is fine although i will note that github renders the 1 and 2 sub-points as part of the outer numbered sequence so it goes 6,7,8,9 -- number 7 in the text is rendered as number 9

likely worth fixing to get meaning across

[hukkin]

Hi @ralexstokes ! This is precisely what this change fixes. Currently the inner list items are actually part of the outer list in Markdown abstract syntax. With the added indentation they truly become a separate inner list and the numbering works as expected when rendered to HTML.

[ralexstokes]

render seems fine and i'm happy w/ the formatting change

[hukkin]

Yup! To clarify, without this change, the list items 1. and 2. are in fact two distinct lists in Markdown abstract syntax (the second list being a list that start indexing from 2). This change makes them list items of a shared list.

[hukkin]

Added one more commit to fix another case where a list was in fact two distinct lists in Markdown syntax.

[djrtwo]

thank you!!

[djrtwo]

@hukkinj1 would it make sense to integrate the formatter into CI? Is the tool generally ready for that?

[hukkin]

@djrtwo yes sure, but it's important to know that the tool is very opinionated, so it may be hard/frustrating for contributors to write Markdown that passes the check. That means that they should actually remember to run the formatter. I'd suggest a few different approaches:

• Don't integrate in CI, but occasionally run the tool manually (not my favorite approach, issues like the ones in this PR will go undetected)
• Integrate in CI, and provide an easy way for contributors to run the formatter as a git pre commit hook (I suggest the pre-commit tool. Essentially we add one configuration file, and the contributor will once run pre-commit install to activate, then forget about it)
• Integrate in CI in a way where CI actually fixes the issues, and doesn't just complain. https://pre-commit.ci/ does exactly that.

[hukkin]

Also if you want a PR to showcase, there is some (intentionally very little) configuration that should be decided upon.

1. Should ordered lists be numbered consecutively, or all items with 1. (note this is perfectly fine according to spec, a Markdown->HTML renderer will render the numbers consecutive regardless). The default non-numbering style is great for minimizing diffs (explained in the docs)
2. Should paragraphs be wrapped, and if yes, what line length. The default is to preserve word wrap (to support semantic line breaks, and again, to minimize diffs) (explained in the docs)
3. Do we want to include plugins, enabling features such as
   • ToC autogeneration
   • Embedded code formatting (formatting Python with Black might make sense here)

[hukkin]

I opened #2291 already so you can have a look at how the formatting changes would look like. It's currently configured to

• preserve word wrap
• number ordered lists consecutively
• no plugins besides the one for GFM support (versus plain CommonMark)

These are effortless to change ofc.