mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 17:26:22 +03:00
[GH-ISSUE #82] Allow enforcing tabs over spaces #67
Labels
No labels
bug
enhancement
enhancement
enhancement
fixed in next
fixed in next
fixed in next
new rule
new rule
new rule
pull-request
question
refactoring
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/markdownlint#67
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.@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?
@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.
@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.
@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.
@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.
MD010simply never applies. It should be a toggle between spaces or tabs.@DavidAnson commented on GitHub (Mar 6, 2018):
I’ll look at deprecating/replacing this rule in a future release.
@DavidAnson commented on GitHub (Mar 6, 2018):
As I research this more, rule
MD010seems 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
MD010by default to avoid being too opinionated out of the box.@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.
MD007MD010MD030adding a consistent option to
MD010might be easier than dealing with a bunch of language specific options like in #383Thank you
@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.
@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.
@NomarCub commented on GitHub (May 5, 2023):
I also have a use case that
ul-indentis 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
Custom list indent width with indentation guides - Feature archive - Obsidian Forum
Live Preview: improve vertical alignment of multiple paragraphs in lists - Feature requests - Obsidian Forum
Customise indent characters - Feature requests - Obsidian Forum)
@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: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! 😉
@NomarCub commented on GitHub (May 6, 2023):
I appreciate your post, but I disagree.
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!