markdownlint icon indicating copy to clipboard operation
markdownlint copied to clipboard

New rule: Prevent lazy continuation lines

Open skwde opened this issue 11 months ago • 3 comments

This is somewhat related to MD032 and emerged from https://github.com/DavidAnson/markdownlint/issues/972

Lazy line conditions make the markdown file less readable. That is because

1. abc
2. def
ghi

behave the same like standard lists

1. abc
2. def
   ghi

Even more confusing/weird is the behavior when using multiple levels like

- abc
  + def
ghi

where ghi goes to the 2nd indent level.

In addition, as mentioned in https://github.com/DavidAnson/markdownlint/blob/main/doc/md032.md some parsers do not parse lists if they are not surrounded by blank lines. MD032 is however only concerned with the starting line because it cannot know when it should be a lazy line continuation or when the list is done.

skwde avatar Sep 15 '23 04:09 skwde

Ditto. This would be a great add :)

BlaineEXE avatar Apr 29 '24 22:04 BlaineEXE

Chiming in here. My coworker Marcel (@ravlen) and I have been talking about this problem over in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/155088 for the GitLab docs. He's trying to construct a rule in Vale to error out on (what I now know are) lazy continuation lines.

While lazy continuation lines are valid CommonMark, I agree with Marcel - when managing Markdown-formatted docs at scale, our technical writing team would find it helpful to prevent them from creeping into our docs. It feels like a good rule to leave off by default, but make available to users who need every scrap of scannability improvements they can get.

amyq avatar Jun 03 '24 21:06 amyq

Yeah, 👍 from me, though I think this is a repeat of the request in https://github.com/DavidAnson/markdownlint/issues/344, where I've got a non-breaking change suggestion that could work in https://github.com/DavidAnson/markdownlint/issues/344#issuecomment-1891542874

Ravlen avatar Jun 04 '24 02:06 Ravlen