mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 09:16:02 +03:00
[GH-ISSUE #23] Enhancement: Custom error messages #18
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#18
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 @originalfoo on GitHub (Jun 19, 2016).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/23
Rules
Currently rules have a static error message, it would be useful if they could generate context-sensitive errors, for example:
Styles
An optional top-level error message that gets output upon the first error for a given batch of documents.
This would be particularly useful in CI builds of open source projects to help guide contributors to the style guide or templates, etc.
@DavidAnson commented on GitHub (Jun 21, 2016):
Makes total sense. Will think about this more and look into it soon! Much appreciated. :)
@originalfoo commented on GitHub (Jun 21, 2016):
On the subject of custom rule errors, it would be useful if configurable rules stated the config in their error message. For example, I just got these CI errors on some doc updates for eslint:
I had to search build scripts to work out what params had been sent to the linter, for example how many spaces should be used for list indentation? It would save time if errors looked like this:
That will enable me, and others, to see at a glance what needs changing to fix an error.
@DavidAnson commented on GitHub (Oct 24, 2016):
This ended up being a bigger task than I expected, but I think it's a significant improvement, thanks for suggesting it!
PS - I did not implement a guidance message because it seems like configuration/process that will be handled differently by various projects (documentation, output message, code comment, etc.).