[GH-ISSUE #502] New rule: No line wrapping #409

New issue

Closed

opened 2026-03-03 01:26:40 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @groenroos on GitHub (Feb 22, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/502

As a sort of antithesis to MD013, I'd want a new (off by default) rule that enforces all paragraphs to be on a single line, with a blank line in between.

Under this proposed rule, this would fail:

A paragraph of text, formatted to fit 80 characters per line, for the most
orthodox way of writing Markdown.  However, imagine having to add a sentence
before this one, and then having to spend the time reorganising all this text
to fully utilise the 80 characters per line to keep it tidy.  Sounds like a
lot of effort for an unclear benefit.

Paragraphs should have an empty line in between.

But this would pass:

This paragraph is on a single line. Most places where you'd write Markdown these days, like GitHub and VSCode, already have built-in dynamic line wrapping that's appropriate to the width of the editor.  You can concentrate on authoring text, rather than tidying it.

Paragraphs should still have an empty line in between.

For what it's worth, I definitely understand the rationale for MD013, and I don't think it should be turned off by default.

But in many modern contexts, code editors and diff viewers have built-in line wrapping, which adjust based on the width of the editor, rather than baked in at <80 characters.

And as far as I can tell, there's also no enforcement that the author does indeed utilise all 80 characters fully, so the linter can let through some annoyingly formatted text;

In this paragraph, there is no consistent line wrapping, and so the
words are wherever
they
happen to
be

On the other hand, if you want to utilise the 80 characters to its fullest, but then had to add a sentence in the middle of a long paragraph, you'd need to spend time manually re-flowing the subsequent text, and cause a less clear git diff in the process.

Additionally, for the work I do, a single line break between text is more often an unintended side effect of pasting content from a WYSIWYG text editor, rather than a deliberate effort by the author.

This is then exacerbated by the fact that some Markdown parsers (like GitHub) treat a newline in the middle of a paragraph as a <br/>, and so this baked-in line wrapping then bleeds into presentation as well. It can become ambiguous where the author did intend a forced line break, and where they were wrapping lines.

For these reasons, I'd like to have the option for a rule that enforces no line wrapping by the author. Turning this rule on would automatically turn MD013 off.

Originally created by @groenroos on GitHub (Feb 22, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/502 As a sort of antithesis to [MD013](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md013---line-length), I'd want a new (off by default) rule that enforces all paragraphs to be on a single line, with a blank line in between. Under this proposed rule, this would **fail**: ```markdown A paragraph of text, formatted to fit 80 characters per line, for the most orthodox way of writing Markdown. However, imagine having to add a sentence before this one, and then having to spend the time reorganising all this text to fully utilise the 80 characters per line to keep it tidy. Sounds like a lot of effort for an unclear benefit. Paragraphs should have an empty line in between. ``` But this would **pass**: ```markdown This paragraph is on a single line. Most places where you'd write Markdown these days, like GitHub and VSCode, already have built-in dynamic line wrapping that's appropriate to the width of the editor. You can concentrate on authoring text, rather than tidying it. Paragraphs should still have an empty line in between. ``` For what it's worth, I definitely understand the rationale for MD013, and I don't think it should be turned off by default. But in many modern contexts, code editors and diff viewers have built-in line wrapping, which adjust based on the width of the editor, rather than baked in at <80 characters. And as far as I can tell, there's also no enforcement that the author does indeed utilise all 80 characters fully, so the linter can let through some annoyingly formatted text; ```markdown In this paragraph, there is no consistent line wrapping, and so the words are wherever they happen to be ``` On the other hand, if you want to utilise the 80 characters to its fullest, but then had to add a sentence in the middle of a long paragraph, you'd need to spend time manually re-flowing the subsequent text, and cause a less clear git diff in the process. Additionally, for the work I do, a single line break between text is more often an unintended side effect of pasting content from a WYSIWYG text editor, rather than a deliberate effort by the author. This is then exacerbated by the fact that some Markdown parsers (like GitHub) treat a newline in the middle of a paragraph as a `<br/>`, and so this baked-in line wrapping then bleeds into presentation as well. It can become ambiguous where the author did intend a forced line break, and where they were wrapping lines. For these reasons, I'd like to have the option for a rule that enforces no line wrapping by the author. Turning this rule on would automatically turn MD013 off.

kerem closed this issue

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

kerem commented

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

Author

Owner

@nschonni commented on GitHub (Feb 22, 2022):

Duplicate of https://github.com/DavidAnson/markdownlint/issues/298

@nschonni commented on GitHub (Feb 22, 2022): Duplicate of https://github.com/DavidAnson/markdownlint/issues/298

kerem commented

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

Author

Owner

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

Agreed. Closing this as Nick has established a link here from there. Thanks for the thorough issue!

@DavidAnson commented on GitHub (Feb 22, 2022): Agreed. Closing this as Nick has established a link here from there. Thanks for the thorough issue!

kerem referenced this issue

2026-03-07 20:05:24 +03:00

[GH-ISSUE #409] MD044: Fixes ignore word definitions #2188