Markdown line length linter #348

Closed
opened 2022-08-21 09:34:21 +00:00 by pat-s · 5 comments
Member

Is set to 80 chars. Do we really want that/need it?

I've never come across a line length linter for non-code, i.e. normal text.
Experienced this in https://drone.gitea.com/gitea/helm-chart/710/1/4, #347.

Is set to 80 chars. Do we really want that/need it? I've never come across a line length linter for non-code, i.e. normal text. Experienced this in https://drone.gitea.com/gitea/helm-chart/710/1/4, #347.
Member

Indeed 80 chars feels a bit short. We could increase it to 120 or even 200 if we want. I would prefer to set a limit generally, because it makes it easier to navigate/read the doc in plaintext while modifying it. Otherwise, you might end up having one large line that gets rendered across multiple lines as a whole paragraph.

Indeed 80 chars feels a bit short. We could increase it to 120 or even 200 if we want. I would prefer to set a limit generally, because it makes it easier to navigate/read the doc in plaintext while modifying it. Otherwise, you might end up having one large line that gets rendered across multiple lines as a whole paragraph.
Author
Member

I would prefer to set a limit generally, because it makes it easier to navigate/read the doc in plaintext while modifying it. Otherwise, you might end up having one large line that gets rendered across multiple lines as a whole paragraph.

I am personally way more distracted if a sentence is split into two lines at any given point than spanning across multiple (wrapped) lines.
Usually there's a difference in editors and editor settings are also the reason for the splitting in the first place (some don't wrap lines but just break directly).

Especially on wide screens such breaks in sentences do not just look odd but also make text hard to read.

I am wondering a bit about this enforcement here in general as this is the first time I do encounter a line length discussion for plain text. Discussing code line length is a different thing (and I am also in the 80 - 100 limit club there) but isn't the "best practice" for plain text:

  • One sentence per line
  • No line breaks

(?)

> I would prefer to set a limit generally, because it makes it easier to navigate/read the doc in plaintext while modifying it. Otherwise, you might end up having one large line that gets rendered across multiple lines as a whole paragraph. I am personally way more distracted if a sentence is split into two lines at any given point than spanning across multiple (wrapped) lines. Usually there's a difference in editors and editor settings are also the reason for the splitting in the first place (some don't wrap lines but just break directly). Especially on wide screens such breaks in sentences do not just look odd but also make text hard to read. I am wondering a bit about this enforcement here in general as this is the first time I do encounter a line length discussion for plain text. Discussing code line length is a different thing (and I am also in the 80 - 100 limit club there) but isn't the "best practice" for plain text: - One sentence per line - No line breaks (?)
Member

Fair points. I guess the limit was just kept enabled by default (see 6033ecf03c/lib/mdl/rules.rb (L214)) but disabled for code blocks and tables. Reference for our .markdownlint.yaml seems to be https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml.

My suggestion to increase the limit instead of removing it is my personal preference. It seems that no actual "best practice" for line length in markdown exists. So I am happy with any outcome of this issue. ?

@luhahn?

Fair points. I guess the limit was just kept enabled by default (see https://github.com/markdownlint/markdownlint/blob/6033ecf03c71767b6625cb97d5f51a247b0d611e/lib/mdl/rules.rb#L214) but disabled for code blocks and tables. Reference for our `.markdownlint.yaml` seems to be https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml. My suggestion to increase the limit instead of removing it is my personal preference. It seems that no actual "best practice" for line length in markdown exists. So I am happy with any outcome of this issue. ? @luhahn?
Author
Member

It seems that no actual "best practice" for line length in markdown exists.

Best practices are always subjective to some degree :D
Increasing is is definitely better than doing nothing, even though I still believe that for plain text no limit should exist.

Maybe let's see what others think?

> It seems that no actual "best practice" for line length in markdown exists. Best practices are always subjective to some degree :D Increasing is is definitely better than doing nothing, even though I still believe that for plain text no limit should exist. Maybe let's see what others think?
Member

I'm fine with increasing the limit :) 80 chars are indeed a bit short

I'm fine with increasing the limit :) 80 chars are indeed a bit short
lunny closed this issue 2022-09-25 15:21:53 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#348
No description provided.