mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 17:26:22 +03:00
[GH-ISSUE #339] Error: Property 'range' of onError parameter is incorrect. #289
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#289
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 @Luc-Olsthoorn on GitHub (Oct 12, 2020).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/339
Trying to validate:
a<pre>) a ( a )[a]~</pre>With these options:
Results in:
Versions:
node/14.0.0"markdownlint": "^0.21.0",@DavidAnson commented on GitHub (Oct 12, 2020):
Sorry about that!
https://dlaa.me/markdownlint/#%25m%23%20Issue%20339%0A%0A%3C!--%20markdownlint-disable%20md033%20--%3E%0A%0Aa%3Cpre%3E%26rpar%3B%20a%20%26lpar%3B%20a%20%26rpar%3B%5Ba%5D~%3C%2Fpre%3E%0A
@DavidAnson commented on GitHub (Oct 13, 2020):
By inspection, the problem seems to be related to the escaped parens (lpar/rpar). Out of curiosity, why is that done here?
@Luc-Olsthoorn commented on GitHub (Oct 13, 2020):
I highly redacted/reduced the code to make it just the bug, but the real reason I think its like that (no human would write something like that), is that our content was originally in XML format and someone before my time used a library/custom code to convert it to markdown. I'm pretty sure its an artifact of that.
It probably could be changed of course, but we have thousands of pieces of content that my linter (which includes markdown lint) needs to be able to process, so who knows what other pieces have this artifact, and when it will crop up again!
@DavidAnson commented on GitHub (Oct 13, 2020):
Makes sense! I'll probably fix this such that there's no range provided for cases like this. There will still be an error on the right line, just no column/length and so no fix. You've disabled the failing rule anyway, so won't notice the limitation.