[GH-ISSUE #82] Allow enforcing tabs over spaces #67

Closed
opened 2026-03-03 01:23:28 +03:00 by kerem · 13 comments
Owner

Originally created by @JoshuaKGoldberg on GitHub (Oct 22, 2017).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/82

For teams where the code style is tabs instead of spaces, linting needs a way to enforce that 4x gets replaced with tabs.

Originally created by @JoshuaKGoldberg on GitHub (Oct 22, 2017). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/82 For teams where the code style is tabs instead of spaces, linting needs a way to enforce that 4x` ` gets replaced with tabs.
kerem 2026-03-03 01:23:28 +03:00
  • closed this issue
  • added the
    new rule
    label
Author
Owner

@DavidAnson commented on GitHub (Oct 22, 2017):

That would seem to be in conflict with: https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md010

I prefer tabs semantically, but tend to feel that documentation (Markdown) should render as uniformly as possible (spaces). Do you have a specific example of where tabs would be necessary in Markdown?

<!-- gh-comment-id:338508678 --> @DavidAnson commented on GitHub (Oct 22, 2017): That would seem to be in conflict with: https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md010 I prefer tabs semantically, but tend to feel that documentation (Markdown) should render as uniformly as possible (spaces). Do you have a specific example of where tabs would be necessary in Markdown?
Author
Owner

@JoshuaKGoldberg commented on GitHub (Oct 23, 2017):

Not necessary, but practical. My use case is that my team at work uses tabs everywhere and wants to keep it standard in all our files.

<!-- gh-comment-id:338532260 --> @JoshuaKGoldberg commented on GitHub (Oct 23, 2017): Not necessary, but practical. My use case is that my team at work uses tabs everywhere and wants to keep it standard in all our files.
Author
Owner

@sensibleish commented on GitHub (Feb 1, 2018):

The Markdown spec at https://daringfireball.net/projects/markdown/basics contains the string "4 spaces or 1 tab" twice. Lint rule MD010 doesn't seem valid, at least not as a blanket rule.

<!-- gh-comment-id:362358203 --> @sensibleish commented on GitHub (Feb 1, 2018): The Markdown spec at https://daringfireball.net/projects/markdown/basics contains the string "4 spaces or 1 tab" twice. Lint rule MD010 doesn't seem valid, at least not as a blanket rule.
Author
Owner

@DavidAnson commented on GitHub (Feb 1, 2018):

@giskard22 I agree with your reading of the specification. That said, there are many projects that impose additional standards and forbidding tab characters like MD010 does is somewhat common. Linking tools will often go beyond what’s allowed by the specification in order to standardize, avoid unwanted practices, and so on. For scenarios where rule MD010 does not apply, it can be disabled.

<!-- gh-comment-id:362360354 --> @DavidAnson commented on GitHub (Feb 1, 2018): @giskard22 I agree with your reading of the specification. That said, there are many projects that impose additional standards and forbidding tab characters like MD010 does is somewhat common. Linking tools will often go beyond what’s allowed by the specification in order to standardize, avoid unwanted practices, and so on. For scenarios where rule MD010 does not apply, it can be disabled.
Author
Owner

@NatoBoram commented on GitHub (Mar 6, 2018):

You having seen "many projects" imposing different standards shouldn't undermine the usability of your project. Linting tools shouldn't promote unwanted practices nor force different standards.

MD010 simply never applies. It should be a toggle between spaces or tabs.

<!-- gh-comment-id:370888390 --> @NatoBoram commented on GitHub (Mar 6, 2018): You having seen "many projects" imposing different standards shouldn't undermine the usability of your project. Linting tools shouldn't promote unwanted practices nor force different standards. `MD010` simply *never* applies. It should be a toggle between spaces or tabs.
Author
Owner

@DavidAnson commented on GitHub (Mar 6, 2018):

I’ll look at deprecating/replacing this rule in a future release.

<!-- gh-comment-id:370930378 --> @DavidAnson commented on GitHub (Mar 6, 2018): I’ll look at deprecating/replacing this rule in a future release.
Author
Owner

@DavidAnson commented on GitHub (Mar 6, 2018):

As I research this more, rule MD010 seems easy to define and implement - but the opposite rule to enforce tabs instead of spaces seems more ambiguous and open to debate.

http://spec.commonmark.org/0.28/#tabs

Many places where a tab could be used are not places I think everyone would agree it should be used, so I think the proposed rule to enforce tabs may need multiple options to support every scenario.

So I will leave this issue as a request to add a new rule for tabs. And separately, I will look at disabling MD010 by default to avoid being too opinionated out of the box.

<!-- gh-comment-id:370956485 --> @DavidAnson commented on GitHub (Mar 6, 2018): As I research this more, rule `MD010` seems easy to define and implement - but the opposite rule to enforce tabs instead of spaces seems more ambiguous and open to debate. http://spec.commonmark.org/0.28/#tabs Many places where a tab *could* be used are not places I think everyone would agree it *should* be used, so I think the proposed rule to enforce tabs may need multiple options to support every scenario. So I will leave this issue as a request to add a new rule for tabs. And separately, I will look at disabling `MD010` by default to avoid being too opinionated out of the box.
Author
Owner

@sww1235 commented on GitHub (May 9, 2021):

I would like to chime in on this, even though it is over 2 years old at this point and add a request for supporting tabs as well.

I would propose that the following rules are modified with a rule to check for tabs, spaces, or consistent styling.

  • MD007
  • MD010
  • MD030

adding a consistent option to MD010 might be easier than dealing with a bunch of language specific options like in #383

Thank you

<!-- gh-comment-id:835857761 --> @sww1235 commented on GitHub (May 9, 2021): I would like to chime in on this, even though it is over 2 years old at this point and add a request for supporting tabs as well. I would propose that the following rules are modified with a rule to check for tabs, spaces, or consistent styling. - `MD007` - `MD010` - `MD030` adding a consistent option to `MD010` might be easier than dealing with a bunch of language specific options like in #383 Thank you
Author
Owner

@groenroos commented on GitHub (Feb 19, 2022):

+1 for implementing a new rule for enforcing indentation with tabs instead of spaces!

While space indentation may be more common in Markdown, I think in a large multi-language project, it's more important that the coding style is fairly consistent across the whole project, rather than orthodox to each individual language.

<!-- gh-comment-id:1045589150 --> @groenroos commented on GitHub (Feb 19, 2022): +1 for implementing a new rule for enforcing indentation with tabs instead of spaces! While space indentation may be more common in Markdown, I think in a large multi-language project, it's more important that the coding style is fairly consistent across the whole project, rather than orthodox to each individual language.
Author
Owner

@AramZS commented on GitHub (Feb 15, 2023):

+1 to tabs over spaces though I will note that YAML requires spaces, so as long as it doesn't mess with the YAML blocks.

<!-- gh-comment-id:1431963971 --> @AramZS commented on GitHub (Feb 15, 2023): +1 to tabs over spaces though I will note that YAML requires spaces, so as long as it doesn't mess with the YAML blocks.
Author
Owner
<!-- gh-comment-id:1536848902 --> @NomarCub commented on GitHub (May 5, 2023): I also have a use case that `ul-indent` is insufficient for as-is, and would need support for tabs. I use Obsidian, which has issues rendering space indentation consistently. (see [Support Indentation Guides for all tab sizes (2 and 3 spaces) - Feature requests - Obsidian Forum](https://forum.obsidian.md/t/support-indentation-guides-for-all-tab-sizes-2-and-3-spaces/34344) [Custom list indent width with indentation guides - Feature archive - Obsidian Forum](https://forum.obsidian.md/t/custom-list-indent-width-with-indentation-guides/34828) [Live Preview: improve vertical alignment of multiple paragraphs in lists - Feature requests - Obsidian Forum](https://forum.obsidian.md/t/live-preview-improve-vertical-alignment-of-multiple-paragraphs-in-lists/33866) [Customise indent characters - Feature requests - Obsidian Forum](https://forum.obsidian.md/t/customise-indent-characters/6076))
Author
Owner

@JoshuaKGoldberg commented on GitHub (May 6, 2023):

Huh, I'd forgotten that I filed this issue. Since filing it I've come to the conclusion that a linter should not be used for formatting concerns such as enforcing tabs vs spaces. Closing this issue and unsubscribing from it, as I use Prettier or dprint to enforce formatting instead of markdownlint.

As of https://github.com/DavidAnson/markdownlint/pull/594, you can use a built-in Markdownlint style/prettier.json (equivalent to eslint-config-prettier) to disable all formatting rules in Markdownlint:

// .markdownlint.json
{
    "extends": "markdownlint/style/prettier"
}

I've got a longer blog post about it here: https://blog.joshuakgoldberg.com/configuring-markdownlint-alongside-prettier (apologies for the shameless self promotion).

If someone else wants to file a new version of this issue, nothing's stopping you. Just know that I'll silently judge you for using a linter for formatting! 😉

<!-- gh-comment-id:1537025462 --> @JoshuaKGoldberg commented on GitHub (May 6, 2023): Huh, I'd forgotten that I filed this issue. Since filing it I've come to the conclusion that [a linter should not be used for formatting concerns such as enforcing tabs vs spaces](https://typescript-eslint.io/linting/troubleshooting/formatting). Closing this issue and unsubscribing from it, as I use [Prettier](https://prettier.io) or [dprint](https://dprint.dev) to enforce formatting instead of markdownlint. As of https://github.com/DavidAnson/markdownlint/pull/594, you can use a built-in Markdownlint `style/prettier.json` (equivalent to [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier)) to disable all formatting rules in Markdownlint: ```jsonc // .markdownlint.json { "extends": "markdownlint/style/prettier" } ``` I've got a longer blog post about it here: https://blog.joshuakgoldberg.com/configuring-markdownlint-alongside-prettier _(apologies for the shameless self promotion)_. If someone else wants to file a new version of this issue, nothing's stopping you. Just know that I'll silently judge you for using a linter for formatting! 😉
Author
Owner

@NomarCub commented on GitHub (May 6, 2023):

I appreciate your post, but I disagree.

  • I don't want one more tool just to enforce this rule.
  • Tabs are not purely syntactic in markdown, they are basically significant whitespace, so this rule is a linting issue, not a formatting one only.
  • Prettier is too opinionated, generic, and not configurable enough for markdown - see this example.

There's been some valuable discussion on this here, and others still want the feature, so please reopen this issue @JoshuaKGoldberg.
Also, thank you for the useful links, never heard of dprint before!

<!-- gh-comment-id:1537065817 --> @NomarCub commented on GitHub (May 6, 2023): I appreciate your post, but I disagree. - I don't want one more tool just to enforce this rule. - Tabs are not purely syntactic in markdown, they are basically significant whitespace, so this rule is a linting issue, not a formatting one only. - Prettier is too opinionated, generic, and not configurable enough for markdown - see [this example](https://stackoverflow.com/questions/64052818/prettier-keeps-replacing-asterisk-characters-with-underscores). There's been some valuable discussion on this here, and others still want the feature, so please reopen this issue @JoshuaKGoldberg. Also, thank you for the useful links, never heard of dprint before!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/markdownlint#67
No description provided.