mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-26 01:36:03 +03:00
[GH-ISSUE #264] Support rule configuration changes via inline comment syntax #228
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#228
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 @koppor on GitHub (Mar 3, 2020).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/264
MD033 allows for adding paramters:
It is unclear how this works with
markdown-lint-disable-fileI tried
Both do not result in
<kbd>Enter</kbd>is ignored.@DavidAnson commented on GitHub (Mar 3, 2020):
The comment syntax above allows one to enable or disable rules by name, but does not allow configuring those rules. If you want to disable MD033, just identify it by that name.
FYI that I have already sketched out a design that would allow inline comments to configure rules. I expect to work on that in the next few weeks.
@DavidAnson commented on GitHub (Mar 3, 2020):
By the way, “disabling” a rule turns it off. Retreading your issue, it seems you want to “enable” MD033 (and configure it).
@koppor commented on GitHub (Mar 4, 2020):
Oh, yes, you are right. I wanted to "disable MD033 for all elements besides kbd" to allow Enter in CHANGELOG.md files. Reason: It renders nice:
Maybe, I ask for
or (simpler syntax as html element names do not contain spaces:
Then one can also do easily
@DavidAnson commented on GitHub (Mar 5, 2020):
You correctly guessed the planned name of the new directive! :) However, I expect to use JSON for the data so that it is consistent with the most common configuration file format. JSON is also validate-able by the user and offers auto-completion in the VS Code extension. But your scenario/proposal maps pretty well to what I had in mind.