starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-26 17:56:02 +03:00

[GH-ISSUE #498] MD035: Horizontal Rule enforcement broken #406

New issue

Closed

opened 2026-03-03 01:26:38 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 01:26:38 +03:00

Owner

Originally created by @TheJaredWilcurt on GitHub (Feb 6, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/498

Dependency versions:

markdownlint-cli: 0.31.1
- markdownlint: 0.25.1
  - markdown-it: 12.3.2

Rule

# MD035 - Horizontal rule style
hr-style:
  style: "* * *"

Description

Previously (0.24.0) using - - - would throw this error:

[Expected: * * *; Actual: - - -]

Now it throws:

[Expected: * * *; Actual: ---]

Same with * * * *

Before: [Expected: * * *; Actual: * * * *]
Now: [Expected: * * *; Actual: ****]

Reproduction

https://dlaa.me/markdownlint

Originally created by @TheJaredWilcurt on GitHub (Feb 6, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/498 ## Dependency versions: * **markdownlint-cli:** `0.31.1` * **markdownlint:** `0.25.1` * **markdown-it:** `12.3.2` ## Rule ```yml # MD035 - Horizontal rule style hr-style: style: "* * *" ``` ## Description Previously (0.24.0) using `- - -` would throw this error: * `[Expected: * * *; Actual: - - -]` Now it throws: * `[Expected: * * *; Actual: ---]` Same with `* * * *` * **Before:** `[Expected: * * *; Actual: * * * *]` * **Now:** `[Expected: * * *; Actual: ****]` ## Reproduction * [https://dlaa.me/markdownlint](https://dlaa.me/markdownlint/#%25m%23%201%0A%0A---%0A%0A5%0A%0A-%20-%20-%0A%0A9%0A%0A***%0A%0A13%0A%0A----%0A%0A17%0A%0A****%0A%0A21%0A%0A*%20*%20*%20*%0A%0A25%0A%0A*%20*%20*%0A%0A29%0A)

kerem

2026-03-03 01:26:38 +03:00

closed this issue
added the
bug

fixed in next
labels

kerem commented

2026-03-03 01:26:39 +03:00

Author

Owner

@TheJaredWilcurt commented on GitHub (Feb 6, 2022):

The above would just be confusing for people, but there is also a functionality bug:

If you set your rule's style to this:

# MD035 - Horizontal rule style
hr-style:
  style: "* * *"

It will take a valid use like * * * and report it as an error, because it is removing the spaces

[Expected: * * *; Actual: ***]

@TheJaredWilcurt commented on GitHub (Feb 6, 2022): The above would just be confusing for people, but there is also a functionality bug: If you set your rule's style to this: ``` # MD035 - Horizontal rule style hr-style: style: "* * *" ``` It will take a valid use like `* * *` and report it as an error, because it is removing the spaces ``` [Expected: * * *; Actual: ***] ```

kerem commented

2026-03-03 01:26:39 +03:00

Author

Owner

@DavidAnson commented on GitHub (Feb 6, 2022):

Ugh, I "improved" this rule by relying more on the parser to identify syntax, but it seems to be normalizing and that leads to this problem.

@DavidAnson commented on GitHub (Feb 6, 2022): Ugh, I "improved" this rule by relying more on the parser to identify syntax, but it seems to be normalizing and that leads to this problem.

kerem commented

2026-03-03 01:26:39 +03:00

Author

Owner

@DavidAnson commented on GitHub (Feb 10, 2022):

The markdown-it parser represents thematic breaks as symbol and count, ignoring spaces as allowed by the CommonMark specification. My recent change to use the parser representation fixed an issue handling thematic breaks in a blockquote and I'd rather not go back to parsing the line manually. I'm tempted to make a change to the rule to ignores spaces so the problem you report will be addressed. However, the rule would then not care about spaces and would allow three asterisks together and three asterisks with a single space in the same document, for example. The rule would become less picky than it is today, so would not start flagging anything that isn't already a violation. However, it would not allow being specific about the number of spaces like it previously did. I think I'm fine with that, but am open to feedback.

@DavidAnson commented on GitHub (Feb 10, 2022): The `markdown-it` parser represents thematic breaks as symbol and count, ignoring spaces as allowed by the CommonMark specification. My recent change to use the parser representation fixed an issue handling thematic breaks in a blockquote and I'd rather not go back to parsing the line manually. I'm tempted to make a change to the rule to ignores spaces so the problem you report will be addressed. However, the rule would then not care about spaces and would allow three asterisks together and three asterisks with a single space in the same document, for example. The rule would become less picky than it is today, so would not start flagging anything that isn't already a violation. However, it would not allow being specific about the number of spaces like it previously did. I think I'm fine with that, but am open to feedback.

kerem commented

2026-03-03 01:26:40 +03:00

Author

Owner

@TheJaredWilcurt commented on GitHub (Feb 13, 2022):

I don't see that as any different to this problem. You're just shifting it from a detection problem, to an enforcement problem. A linter should allow you to enforce stylistic choices. I shouldn't have to manually change someone else's PR to convert all the *** to * * * to match the rest of the code and maintain consistency, the linter should be able to handle that.

Also in some Markdown interpreters (like Haroopad), Different ways of writing an <hr> result in different classes being applied in the output to give greater choice in how impactful the HR is visually. This doesn't impact me, but may be relevant to others.

The more I learn about markdown-it the more I do not like it.

@TheJaredWilcurt commented on GitHub (Feb 13, 2022): I don't see that as any different to this problem. You're just shifting it from a detection problem, to an enforcement problem. A linter should allow you to enforce stylistic choices. I shouldn't have to manually change someone else's PR to convert all the `***` to `* * *` to match the rest of the code and maintain consistency, the linter should be able to handle that. Also in some Markdown interpreters (like Haroopad), Different ways of writing an `<hr>` result in different classes being applied in the output to give greater choice in how impactful the HR is visually. This doesn't impact me, but may be relevant to others. The more I learn about `markdown-it` the more I do not like it.

kerem commented

2026-03-03 01:26:40 +03:00

Author

Owner

@DavidAnson commented on GitHub (Feb 13, 2022):

Fair points. I have an idea how to be picky in the current context and will explore that when I get to this issue. It sounds like you want the freedom to define a break as "* * *" and have that exclusively enforced.

Unrelated, I don't think it's fair to blame markdown-it for any problems related to this project. I'm (ab)using it for a purpose it wasn't intended to support. :)

@DavidAnson commented on GitHub (Feb 13, 2022): Fair points. I have an idea how to be picky in the current context and will explore that when I get to this issue. It sounds like you want the freedom to define a break as "* * *" and have that exclusively enforced. Unrelated, I don't think it's fair to blame `markdown-it` for any problems related to this project. I'm (ab)using it for a purpose it wasn't intended to support. :)

kerem commented

2026-03-03 01:26:40 +03:00

Author

Owner

@TheJaredWilcurt commented on GitHub (Feb 25, 2022):

Yes, I want to continue enforcing that, it is currently the last of my breaking tests preventing me from updating my markdownlint ruleset from 0.16.0 to latest (0.25.X).

https://github.com/tjw-lint/tjw-markdownlint-rules/pull/3

I'm excited to get that fixed/merged/released, as there are new rules that have been added to markdownlint that I had been waiting for.

@TheJaredWilcurt commented on GitHub (Feb 25, 2022): Yes, I want to continue enforcing that, it is currently the last of my breaking tests preventing me from updating my markdownlint ruleset from 0.16.0 to latest (0.25.X). * https://github.com/tjw-lint/tjw-markdownlint-rules/pull/3 I'm excited to get that fixed/merged/released, as there are new rules that have been added to markdownlint that I had been waiting for.

kerem referenced this issue

2026-03-03 01:30:31 +03:00

[PR #406] [MERGED] Correct typo in JSON schema type keyword #861

kerem referenced this issue

2026-03-07 20:10:12 +03:00

[PR #406] [MERGED] Correct typo in JSON schema type keyword #2709