[GH-ISSUE #17] ignore hard-tabs in code block #11

New issue

Closed

opened 2026-03-03 01:23:00 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 01:23:00 +03:00

Owner

Originally created by @liyongjing on GitHub (Apr 23, 2016).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/17

for example

func main() {
    r := gin.Default()
    r.GET("/", func(c *gin.Context) {
        c.String(http.StatusOK, "Hello from %v", "Gin")
    })

    r.Run(":3000")
}

Originally created by @liyongjing on GitHub (Apr 23, 2016). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/17 for example ``` go func main() { r := gin.Default() r.GET("/", func(c *gin.Context) { c.String(http.StatusOK, "Hello from %v", "Gin") }) r.Run(":3000") } ```

kerem

2026-03-03 01:23:00 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-03 01:23:01 +03:00

Author

Owner

@DavidAnson commented on GitHub (Apr 23, 2016):

In my mind, hard tabs are a problem because no two tools agree on how many spaces they should be. For example here on GitHub, they've converted the tabs in your example to 4 spaces, though it's common to see 8-space or 2-space tabs. Because of this, I consider tabs equally problematic inside code blocks as they are outside and I think this warning is correct to fire inside a code block.

Does that seem reasonable?

@DavidAnson commented on GitHub (Apr 23, 2016): In my mind, hard tabs are a problem because no two tools agree on how many spaces they should be. For example here on GitHub, they've converted the tabs in your example to 4 spaces, though it's common to see 8-space or 2-space tabs. Because of this, I consider tabs equally problematic inside code blocks as they are outside and I think this warning is correct to fire inside a code block. Does that seem reasonable?

kerem commented

2026-03-03 01:23:01 +03:00

Author

Owner

@wiryls commented on GitHub (Apr 10, 2018):

@DavidAnson Sorry to bother you. The explanation is very reasonable.
But go recommends tabs instead of spaces. And almost all go projects are using tabs (in 2016).

Waiting for #82 being resolved in the future :-)

@wiryls commented on GitHub (Apr 10, 2018): @DavidAnson Sorry to bother you. The explanation is very reasonable. But [go recommends tabs instead of spaces](https://stackoverflow.com/a/19094725). And [almost all go projects are using tabs](https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd) (in 2016). Waiting for #82 being resolved in the future :-)

kerem commented

2026-03-03 01:23:01 +03:00

Author

Owner

@jasonkarns commented on GitHub (Jul 26, 2025):

In addition to go, Makefiles require them. And gitconfig uses them conventionally.

Having hard-tabs fail in code blocks by default makes it difficult to use markdown lint in Super-linter. (A goal of using superlinter being to minimize cross-project configuration, so using a single meta linter across projects, and reusing github action workflows prevents the configuration from being possible. Instead requires markdown linting to be disabled in order for super linter to pass.)

@jasonkarns commented on GitHub (Jul 26, 2025): In addition to go, Makefiles require them. And gitconfig uses them conventionally. Having hard-tabs fail in code blocks _by default_ makes it difficult to use markdown lint in Super-linter. (A goal of using superlinter being to minimize cross-project configuration, so using a single meta linter across projects, and reusing github action workflows prevents the configuration from being possible. Instead requires markdown linting to be disabled in order for super linter to pass.)

kerem commented

2026-03-03 01:23:01 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jul 26, 2025):

@jasonkarns, this rule can be disabled by line, by file, or by project. Additionally, it can be configured to ignore code blocks or to ignore specific languages within code fences. Lint tools tend to be opinionated and that's unlikely to please all of the people all of the time. However, you should already have what you need to configure this rule to suit your taste.

@DavidAnson commented on GitHub (Jul 26, 2025): @jasonkarns, this rule can be disabled by line, by file, or by project. Additionally, it can be configured to ignore code blocks or to ignore specific languages within code fences. Lint tools tend to be opinionated and that's unlikely to please all of the people all of the time. However, you should already have what you need to configure this rule to suit your taste.

kerem referenced this issue

2026-03-07 20:02:09 +03:00

[GH-ISSUE #11] Rule MD004 incorrectly flagging on an Ordered List #1855