[GH-ISSUE #80] Option to auto-fix rules?

kerem commented

2026-03-03 01:23:26 +03:00

Owner

Originally created by @JoshuaKGoldberg on GitHub (Oct 22, 2017).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/80

For simple ones like indentation level complaints, how about providing an API to suggest fixes? Other linters such as ESLint and TSLint are doing this, and it's quite convenient (especially when editor extensions support it).

Originally created by @JoshuaKGoldberg on GitHub (Oct 22, 2017). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/80 For simple ones like indentation level complaints, how about providing an API to suggest fixes? Other linters such as ESLint and TSLint are doing this, and it's quite convenient (especially when editor extensions support it).

kerem

2026-03-03 01:23:26 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@JoshuaKGoldberg commented on GitHub (Oct 22, 2017):

See https://github.com/DavidAnson/vscode-markdownlint/issues/13.

IMO, it's a much better dev experience to embed fix information in the original rule itself (the way ESLint and TSLint do it).

If rule violation complaints get out of sync with their fixes, the fixes can become buggy. Fixing the fixes then requires accounting for both the old and new versions of the package.
Not providing rule fixes makes each package using this library (CLI, extensions, ...) have to separately implement autofixing until a standard package does it.
- In writing autolesshint, which is separate from lesshint, I ended with a lot of duplicate logic around package setup and CLI runtimes

@JoshuaKGoldberg commented on GitHub (Oct 22, 2017): See https://github.com/DavidAnson/vscode-markdownlint/issues/13. IMO, it's a much better dev experience to embed fix information in the original rule itself (the way ESLint and TSLint do it). * If rule violation complaints get out of sync with their fixes, the fixes can become buggy. Fixing the fixes then requires accounting for both the old and new versions of the package. * Not providing rule fixes makes each package using this library (CLI, extensions, ...) have to separately implement autofixing until a standard package does it. * In writing autolesshint, which is separate from lesshint, I ended with a lot of duplicate logic around package setup and CLI runtimes

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 22, 2017):

Thanks! I’m evaluating how auto-fix works in practice in the VS Code extension. If it is a success, I will likely centralize it here as happened with highlighting.

@DavidAnson commented on GitHub (Oct 22, 2017): Thanks! I’m evaluating how auto-fix works in practice in the VS Code extension. If it is a success, I will likely centralize it here as happened with highlighting.

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@KvanTTT commented on GitHub (Oct 28, 2017):

I'm working on MarkConv utility that can convert markdowns of different kinds (GitHub, VisualCode, Habrahabr). Also, it warns about some style issues. Maybe it will be interesting and helpful for you.

@KvanTTT commented on GitHub (Oct 28, 2017): I'm working on [MarkConv](https://github.com/KvanTTT/MarkConv) utility that can convert markdowns of different kinds (GitHub, VisualCode, Habrahabr). Also, it warns about some style issues. Maybe it will be interesting and helpful for you.

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 28, 2017):

@KvanTTT Interesting! Maybe also have a look at Pandoc which does something similar (I have never tried it): http://pandoc.org/

@DavidAnson commented on GitHub (Oct 28, 2017): @KvanTTT Interesting! Maybe also have a look at Pandoc which does something similar (I have never tried it): http://pandoc.org/

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@KvanTTT commented on GitHub (Oct 28, 2017):

I know about pandoc but it supports not all features required for me.

@KvanTTT commented on GitHub (Oct 28, 2017): I know about pandoc but it supports not all features required for me.

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@timocov commented on GitHub (Jan 13, 2018):

Seems that markdown-it does not support generating markdown from AST :(

@timocov commented on GitHub (Jan 13, 2018): Seems that `markdown-it` does not support generating markdown from AST :(

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jan 13, 2018):

Maybe have a look at what I have done in the VS Code extension. It can now fix about 15 rules automatically. Those are all of the ones that are unambiguous. There is another set of rules that can probably never be fixed automatically because it’s not possible to know what the right change is. And then there is a middle set that could maybe be fixed automatically, but would probably be unreliable because of the uncertainty. Not being able to use the parser is unfortunate, but not catastrophic as some rules that you’d want to fix are broken specifically because they do not parse successfully as Markdown.

@DavidAnson commented on GitHub (Jan 13, 2018): Maybe have a look at what I have done in the VS Code extension. It can now fix about 15 rules automatically. Those are all of the ones that are unambiguous. There is another set of rules that can probably never be fixed automatically because it’s not possible to know what the right change is. And then there is a middle set that could maybe be fixed automatically, but would probably be unreliable because of the uncertainty. Not being able to use the parser is unfortunate, but not catastrophic as some rules that you’d want to fix are broken specifically because they do not parse successfully as Markdown.

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@timocov commented on GitHub (Jan 16, 2018):

@DavidAnson could you take a look at github.com/timocov/markdownlint@e2f674beea please?

Possible this issue should be fixed something like that, but I am not sure and your comments will be very helpful to continue work.

@timocov commented on GitHub (Jan 16, 2018): @DavidAnson could you take a look at https://github.com/timocov/markdownlint/commit/e2f674beeaeb489b2c21b5993fa17772997e1fe4 please? Possible this issue should be fixed something like that, but I am not sure and your comments will be very helpful to continue work.

kerem commented

2026-03-03 01:23:27 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jan 16, 2018):

This looks vaguely like one path I have considered. Some loose thoughts off the top of my head (in a meeting):

What happens if two rules want to modify the same line?
Is there an ordering dependency?
What if changes conflict?
It would be nice to run the fix code only when necessary.
Rather than a new field on the rule, would be nice if this was part of the result object? See what I am doing with regexp in the next commit.
Need to maintain possibly mixed line endings in the source file when writing changes.
How are the various failures reported?
How does this integrate with the VS Code extension?
More?

Also, FYI that I am in the middle of significant refactoring in next branch to enable user-defined rules, so I would caution against many changes to master in the near term.

@DavidAnson commented on GitHub (Jan 16, 2018): This looks vaguely like one path I have considered. Some loose thoughts off the top of my head (in a meeting): - What happens if two rules want to modify the same line? - Is there an ordering dependency? - What if changes conflict? - It would be nice to run the fix code only when necessary. - Rather than a new field on the rule, would be nice if this was part of the result object? See what I am doing with `regexp` in the next commit. - Need to maintain possibly mixed line endings in the source file when writing changes. - How are the various failures reported? How does this integrate with the VS Code extension? - More? Also, FYI that I am in the middle of significant refactoring in `next` branch to enable user-defined rules, so I would caution against many changes to `master` in the near term.

kerem commented

2026-03-03 01:23:28 +03:00

Author

Owner

@JoshuaKGoldberg commented on GitHub (Jan 16, 2018):

Not to toot my own projects, but https://github.com/automutate/automutate answers a bunch of those questions 😉

In general, most linters apply "waves" of change/fix/mutation proposals. Mutations are removed until there are no overlaps, then all are applied in last-to-first order.

@JoshuaKGoldberg commented on GitHub (Jan 16, 2018): Not to toot my own projects, but https://github.com/automutate/automutate answers a bunch of those questions 😉 In general, most linters apply "waves" of change/fix/mutation proposals. Mutations are removed until there are no overlaps, then all are applied in last-to-first order.

kerem commented

2026-03-03 01:23:28 +03:00

Author

Owner

@KaiSchwarz-cnic commented on GitHub (Jun 7, 2018):

Morning! How can that autofix be activated in vscode? or is it activated by default?

@KaiSchwarz-cnic commented on GitHub (Jun 7, 2018): Morning! How can that autofix be activated in vscode? or is it activated by default?

kerem commented

2026-03-03 01:23:28 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 7, 2018):

For how to auto-fix rules in the VS Code extension, please see the bottom of this section: https://github.com/DavidAnson/vscode-markdownlint/blob/master/README.md#rules

@DavidAnson commented on GitHub (Jun 7, 2018): For how to auto-fix rules in the VS Code extension, please see the bottom of this section: https://github.com/DavidAnson/vscode-markdownlint/blob/master/README.md#rules

kerem referenced this issue

2026-03-07 20:02:35 +03:00

[GH-ISSUE #65] support for frontmatter in the middle of the text #1900

Rows
Columns

[GH-ISSUE #80] Option to auto-fix rules? #65