MD007: Detect _Unordered list indentation_ based on Tab Size?

[kenorb]

When I've Tab Size of 4 (which I think it's default), when generating TOC via markdown-toc, the markdownlint complains about:

MD007 - Unordered list indentation

I've checked, and in settings I had Editor: Tab Size set to 4. When changed to 2, TOC has been regenerated to use 2 spaces. So I think TOC extension works as expected (it changes on settings), however markdownlint doesn't respect the value of Tab Size.

I think it should read what's set for Editor: Tab Size and rely on that.

Related: alanwalk/markdown-toc/issues/60

[DavidAnson]

https://github.com/DavidAnson/markdownlint is a library that isn’t associated with any editor or workflow. It reads its configuration from a JSON file in a standard manner for libraries (e.g., ESLint).

Based on the issue you linked, you seem to be referring to the https://github.com/DavidAnson/vscode-markdownlint project which wraps this library for use with the VS Code editor. In that case, configuration is still preferred from the config file for consistency with CLI tools and CI workflows. More about that here: https://github.com/DavidAnson/vscode-markdownlint/blob/master/README.md#markdownlintconfig

You can imagine how difficult it would be to work on a project where everyone reformatted content according to their own personal settings/preferences.

If I did make a change here, editor settings would probably have the lowest priority and I’m not sure that’s what you want. I’ll think about this more.

[DavidAnson]

Pressing the Tab key in VS Code can be configured to insert a tab character or some number of spaces (4 by default). https://code.visualstudio.com/docs/editor/codebasics#_indentation

In a Markdown file, the CommonMark specification says that tab characters always correspond to 4 (space) characters. https://spec.commonmark.org/0.29/#tabs

Therefore, the only sensible configuration for editing Markdown in VS Code is to have editor.tabSize set to the default value of 4 spaces. Any other value means that files with tabs vs. those with spaces will have different structure and rendering after the same edits have been applied by the user.

The fact that other Markdown extensions change their behavior based on editor.tabSize seems problematic. For example, generating a table of contents by building an unordered list with editor.tabSize set to 1 would result in incorrectly nested structure because one space is not enough to start a sublist. Similarly, an editor.tabSize setting of 6 or more would cause problems because that is too many to start a sublist. (Examples of both.)

The only way to reliably generate content is for extensions to ignore editor.tabSize and use a constant number of spaces.

For unordered lists, both 2 and 4 spaces are valid. Neither is unambiguously correct, so either might reasonably be used within a file. https://spec.commonmark.org/0.29/#motivation

Which is why this project's MD007/ul-indent rule can be configured to support either approach (though it defaults to 2). https://github.com/DavidAnson/markdownlint/blob/v0.15.0/doc/Rules.md#md007

It is reasonable to ask that VS Code Markdown extensions come up with a way to agree on this value, and I would be open to doing so. However, I believe I have shown here that editor.tabSize is not the right choice.