starred/markdownlint

Fork 0

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

[GH-ISSUE #67] MD013 (line-length) and emphasized links #56

New issue

Closed

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

kerem commented

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

Owner

Originally created by @EvgenyOrekhov on GitHub (Jul 21, 2017).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/67

It is impossible to break these examples into multiple lines:

*[Open a pull request](https://help.github.com/articles/using-pull-requests/ "Using pull requests · GitHub Help")*

**[Open a pull request](https://help.github.com/articles/using-pull-requests/ "Using pull requests · GitHub Help")**

I think MD013 (line-length) should ignore these cases.

Originally created by @EvgenyOrekhov on GitHub (Jul 21, 2017). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/67 It is impossible to break these examples into multiple lines: ```md *[Open a pull request](https://help.github.com/articles/using-pull-requests/ "Using pull requests · GitHub Help")* ``` ```md **[Open a pull request](https://help.github.com/articles/using-pull-requests/ "Using pull requests · GitHub Help")** ``` I think MD013 (line-length) should ignore these cases.

kerem

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

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

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

Author

Owner

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

Whitespace/newlines are supported with links: http://spec.commonmark.org/0.27/#links

*[Open a pull request](
https://help.github.com/articles/using-pull-requests/
"Using pull requests - GitHub Help"
)*

Link references can also be used and also support whitespace/newlines: http://spec.commonmark.org/0.27/#link-reference-definitions

*[Open a pull request][opr]*

text

[opr]:
https://help.github.com/articles/using-pull-requests/
"Using pull requests - GitHub Help"

I think this covers your scenario without needing changes to MD013?

Link to playground to try

@DavidAnson commented on GitHub (Jul 22, 2017): Whitespace/newlines are supported with links: http://spec.commonmark.org/0.27/#links ```md *[Open a pull request]( https://help.github.com/articles/using-pull-requests/ "Using pull requests - GitHub Help" )* ``` Link references can also be used and also support whitespace/newlines: http://spec.commonmark.org/0.27/#link-reference-definitions ```md *[Open a pull request][opr]* text [opr]: https://help.github.com/articles/using-pull-requests/ "Using pull requests - GitHub Help" ``` I think this covers your scenario without needing changes to `MD013`? **[Link to playground to try](https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%2A%5BOpen%20a%20pull%20request%5D%28%5Cnhttps%3A%2F%2Fhelp.github.com%2Farticles%2Fusing-pull-requests%2F%5Cn%5C%22Using%20pull%20requests%20-%20GitHub%20Help%5C%22%5Cn%29%2A%5Cn%5Cntext%5Cn%5Cn%2A%5BOpen%20a%20pull%20request%5D%5Bopr%5D%2A%5Cn%5Cntext%5Cn%5Cn%5Bopr%5D%3A%5Cnhttps%3A%2F%2Fhelp.github.com%2Farticles%2Fusing-pull-requests%2F%5Cn%5C%22Using%20pull%20requests%20-%20GitHub%20Help%5C%22%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D)**

kerem commented

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

Author

Owner

@EvgenyOrekhov commented on GitHub (Jul 22, 2017):

@DavidAnson If the goal of markdownlint is to support only the CommonMark specification, then yes, it does. And in that case 0c1f403 should be reverted.

@EvgenyOrekhov commented on GitHub (Jul 22, 2017): @DavidAnson If the goal of markdownlint is to support only the CommonMark specification, then yes, it does. And in that case 0c1f403 should be reverted.

kerem commented

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

Author

Owner

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

I like using the CommonMark specification because it is clear, well written, and seems to be the thing most people are moving toward. I realize not all parsers completely support it, but it acts as a good reference point and basis for decision-making.

In the case of the previous issue, perhaps I should not have supported that scenario. However, it seems like the kind of thing an average user might try to do and it's nice to give them something that works without having to read a specification or change to a different parser.

This issue is only slightly more complicated, so I will probably handle it as well - but the thing I want to avoid is chasing more scenarios like this that are increasingly difficult and rare in practice.

@DavidAnson commented on GitHub (Jul 22, 2017): I like using the CommonMark specification because it is clear, well written, and seems to be the thing most people are moving toward. I realize not all parsers completely support it, but it acts as a good reference point and basis for decision-making. In the case of the previous issue, perhaps I should not have supported that scenario. However, it seems like the kind of thing an average user might try to do and it's nice to give them something that works without having to read a specification or change to a different parser. This issue is only slightly more complicated, so I will probably handle it as well - but the thing I want to avoid is chasing more scenarios like this that are increasingly difficult and rare in practice.

kerem commented

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

Author

Owner

@EvgenyOrekhov commented on GitHub (Jul 22, 2017):

@DavidAnson A linter absolutely should give a warning if a piece of code can be rewritten in a better way. But again, if the goal of markdownlint is to help write markdown that is going to be properly rendered in all the different markdown parsers, then markdownlint should stick to a subset of markdown and should not warn on the cases where the code can't be rewritten.

@EvgenyOrekhov commented on GitHub (Jul 22, 2017): @DavidAnson A linter absolutely should give a warning if a piece of code can be rewritten in a better way. But again, if the goal of markdownlint is to help write markdown that is going to be properly rendered in all the different markdown parsers, then markdownlint should stick to a subset of markdown and should not warn on the cases where the code can't be rewritten.

kerem referenced this issue

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

[GH-ISSUE #56] rule MD034 flags URL in fenced block as "bare url", unlike mdl #1895