mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 09:16:02 +03:00
[GH-ISSUE #140] MD029 Allow repeating zero's #120
Labels
No labels
bug
enhancement
enhancement
enhancement
fixed in next
fixed in next
fixed in next
new rule
new rule
new rule
pull-request
question
refactoring
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/markdownlint#120
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @boweeb on GitHub (Jul 31, 2018).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/140
In addition to "one" and "ordered" may we also have a "zero" option? In my personal opinion, using a zero is a better hint to the author and/or reader that using the
0/0/0pattern is intentional (in anticipation of parsers that auto-number) and I've written many docs as such.A different implementation might be to support any repeating number (
n/n/n) with aconsistentoption but I can't imagine a scenario someone wanting to use a different number than zero or one.Thoughts? Too edge-case?
This example is the closest reference I could find in the commonmark spec.
@boweeb commented on GitHub (Jul 31, 2018):
A bit tangential but the commonmark example linked above also shows that ordered lists may start with zero and
markdownlintdoesn't appear to support that.@DavidAnson commented on GitHub (Jul 31, 2018):
This has never come up, but seems legitimate. Lists that begin with 0 should be allowed per the specification. Which means 0/0/0 will be possible and so a new “zero” mode seems reasonable.
@gimbo commented on GitHub (Feb 9, 2019):
Isn't starting with zero just a special case of starting with any number, which the spec seems to allow? See also e.g. this example in the spec.
"Start numbers" are also mentioned in the section on list items where there seem to be some circumstances where "the start number must be 1", so maybe it's not possible in general. I'm afraid I'm not familiar enough with the spec, or this tool, enough to grok this - I just came across this while using your marvellous vscode extension, did a bit of digging, and came here... Thought I'd mention it in case it gets some attention from someone qualified to fix it. :-) . So that would allow an "x/x+1/x+2" pattern...?
@DavidAnson commented on GitHub (Feb 9, 2019):
I think what you say is correct - but as a linter, this tool is opinionated about what should be allowed instead of allowing everything that is possible. The supported modes and the “zero“ mode seem well defined and common/meaningful; a scenario where a lists starts with any other number and increases feels like it would be an error more often than not and therefore it makes sense to warn when that is encountered.
@gimbo commented on GitHub (Feb 11, 2019):
Ah yes, good point, I wasn't looking at the linter in the right way there, but I totally see what you mean. I'd still love to see zeroes as a common special case though. :-)
@DavidAnson commented on GitHub (Feb 11, 2019):
Should be in the next round of updates!