[GH-ISSUE #1114] Store rule config in editorconfig compatible files

kerem commented

2026-03-07 20:07:57 +03:00

Owner

Originally created by @sgryphon on GitHub (Jan 29, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1114

There are already several ways to store rule configuration (JSON, yaml, etc).

Consider adding a format that is suitable to be stored in .editorconfig files (https://editorconfig.org/).

The editorconfig standard is for generic rules, like using tabs or spaces, and the amount of indent. (And editors will already apply things like the number of indents spaces to markdown files).

However, several editors have added their own extensions (like ij_ or vs_), and several have collaborated on shared domain/language extensions (like csharp_, ts_, etc).

Although a markdownlint config file could be shared between editors/tools, it might make sense to instead standardise on putting them into an editorconfig file.

Note that tools like Rider, based on ItelliJ, already have some custom editorconfig rules for markdown, e.g. ij_markdown_force_one_space_after_header_symbol, which is very similar to the rule MD019 and MD018.

If you do implement, I suggest collaborating with Rider / IntelliJ ... if there are a least a couple of major editors implementing a standard approach, then it would be good to remove the editor prefix and just have markdown_force_one_space_after_header_symbol, which would auto-format to satisfy rules 18 & 19.

Originally created by @sgryphon on GitHub (Jan 29, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1114 There are already several ways to store rule configuration (JSON, yaml, etc). Consider adding a format that is suitable to be stored in .editorconfig files (https://editorconfig.org/). The editorconfig standard is for generic rules, like using tabs or spaces, and the amount of indent. (And editors will already apply things like the number of indents spaces to markdown files). However, several editors have added their own extensions (like ij_ or vs_), and several have collaborated on shared domain/language extensions (like csharp_, ts_, etc). Although a markdownlint config file could be shared between editors/tools, it might make sense to instead standardise on putting them into an editorconfig file. Note that tools like Rider, based on ItelliJ, already have some custom editorconfig rules for markdown, e.g. `ij_markdown_force_one_space_after_header_symbol`, which is very similar to the rule `MD019` and `MD018`. If you do implement, I suggest collaborating with Rider / IntelliJ ... if there are a least a couple of major editors implementing a standard approach, then it would be good to remove the editor prefix and just have `markdown_force_one_space_after_header_symbol`, which would auto-format to satisfy rules 18 & 19.

kerem

2026-03-07 20:07:57 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@sgryphon commented on GitHub (Jan 29, 2024):

For reference, the IntelliJ rules, exported from Rider:

ij_markdown_force_one_space_after_blockquote_symbol = true
ij_markdown_force_one_space_after_header_symbol = true
ij_markdown_force_one_space_after_list_bullet = true
ij_markdown_force_one_space_between_words = true
ij_markdown_format_tables = true
ij_markdown_insert_quote_arrows_on_wrap = true
ij_markdown_keep_indents_on_empty_lines = false
ij_markdown_keep_line_breaks_inside_text_blocks = true
ij_markdown_max_lines_around_block_elements = 1
ij_markdown_max_lines_around_header = 1
ij_markdown_max_lines_between_paragraphs = 1
ij_markdown_min_lines_around_block_elements = 1
ij_markdown_min_lines_around_header = 1
ij_markdown_min_lines_between_paragraphs = 1
ij_markdown_wrap_text_if_long = true
ij_markdown_wrap_text_inside_blockquotes = true

@sgryphon commented on GitHub (Jan 29, 2024): For reference, the IntelliJ rules, exported from Rider: ``` ij_markdown_force_one_space_after_blockquote_symbol = true ij_markdown_force_one_space_after_header_symbol = true ij_markdown_force_one_space_after_list_bullet = true ij_markdown_force_one_space_between_words = true ij_markdown_format_tables = true ij_markdown_insert_quote_arrows_on_wrap = true ij_markdown_keep_indents_on_empty_lines = false ij_markdown_keep_line_breaks_inside_text_blocks = true ij_markdown_max_lines_around_block_elements = 1 ij_markdown_max_lines_around_header = 1 ij_markdown_max_lines_between_paragraphs = 1 ij_markdown_min_lines_around_block_elements = 1 ij_markdown_min_lines_around_header = 1 ij_markdown_min_lines_between_paragraphs = 1 ij_markdown_wrap_text_if_long = true ij_markdown_wrap_text_inside_blockquotes = true ```

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jan 29, 2024):

I’ve looked into a suggestion like this previously and it did not seem to me that editorconfig was intended for - or was particularly welcoming to - this kind of customization.

https://github.com/DavidAnson/markdownlint-cli2/issues/179

That said, the library does not restrict where it’s config object comes from and it’s possible to do something like what you propose today with a custom configuration parser.

https://github.com/DavidAnson/markdownlint#optionsconfigparsers
https://github.com/DavidAnson/markdownlint#parsers

@DavidAnson commented on GitHub (Jan 29, 2024): I’ve looked into a suggestion like this previously and it did not seem to me that editorconfig was intended for - or was particularly welcoming to - this kind of customization. <https://github.com/DavidAnson/markdownlint-cli2/issues/179> That said, the library does not restrict where it’s config object comes from and it’s possible to do something like what you propose today with a custom configuration parser. <https://github.com/DavidAnson/markdownlint#optionsconfigparsers> <https://github.com/DavidAnson/markdownlint#parsers>

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@FloEdelmann commented on GitHub (Jan 29, 2024):

NB: Ktlint, a linter for the Kotlin language, also stores its configuration in .editorconfig: https://pinterest.github.io/ktlint/latest/rules/configuration-ktlint/

@FloEdelmann commented on GitHub (Jan 29, 2024): NB: [Ktlint](https://pinterest.github.io/ktlint/latest/), a linter for the Kotlin language, also stores its configuration in `.editorconfig`: https://pinterest.github.io/ktlint/latest/rules/configuration-ktlint/

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@sgryphon commented on GitHub (Jan 29, 2024):

I’ve looked into a suggestion like this previously

Sorry, I did search for existing items in vscode and this repo, but not the CLI one.

If you have already looked into it, and decided not to do it, then fine. But there clearly is some interest, and the way the config is set up for multiple sources probably doesn't make it too hard.

The more tricky ones would be common things like max line length, which if I set in .editorconfig, it's not good if a linter (and formatter, if it can autofix) doesn't parse that.

Great project by the way, and there are options to align the configs already (just have to set it in multiple places)

@sgryphon commented on GitHub (Jan 29, 2024): > I’ve looked into a suggestion like this previously Sorry, I did search for existing items in vscode and this repo, but not the CLI one. If you have already looked into it, and decided not to do it, then fine. But there clearly is some interest, and the way the config is set up for multiple sources probably doesn't make it too hard. The more tricky ones would be common things like max line length, which if I set in .editorconfig, it's not good if a linter (and formatter, if it can autofix) doesn't parse that. Great project by the way, and there are options to align the configs already (just have to set it in multiple places)

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jan 29, 2024):

In the case of settings that overlap, I understand wanting to specify them just once in a common location. However, per my comments in the linked issue, I don't see a clean way to map the current core settings onto the structure of rules used by this tool.

In the case of settings that are unique, why is it that people want to put them in an editor configuration file? Is it just because one file is better than two files? Pedantically, I think some rules do not make sense in a collection of editor preferences because they are correctness issues instead of style choices.

For what it's worth, it appears the editor config folks have been discussing this idea since 2017 and still don't agree on whether to endorse this: https://github.com/editorconfig/editorconfig/issues/332

@DavidAnson commented on GitHub (Jan 29, 2024): In the case of settings that overlap, I understand wanting to specify them just once in a common location. However, per my comments in the linked issue, I don't see a clean way to map the current core settings onto the structure of rules used by this tool. In the case of settings that are unique, why is it that people want to put them in an editor configuration file? Is it just because one file is better than two files? Pedantically, I think some rules do not make sense in a collection of editor preferences because they are correctness issues instead of style choices. For what it's worth, it appears the editor config folks have been discussing this idea since 2017 and still don't agree on whether to endorse this: https://github.com/editorconfig/editorconfig/issues/332

kerem commented

2026-03-07 20:07:59 +03:00

Author

Owner

@cxw42 commented on GitHub (Sep 28, 2024):

For whatever it may be worth, editorconfig files do expressly accept custom keys --- https://spec.editorconfig.org/index.html#supported-pairs . The discussion in https://github.com/editorconfig/editorconfig/issues/332 is about how to manage the already-expanding universe of such keys.

@cxw42 commented on GitHub (Sep 28, 2024): For whatever it may be worth, editorconfig files do expressly accept custom keys --- https://spec.editorconfig.org/index.html#supported-pairs . The discussion in https://github.com/editorconfig/editorconfig/issues/332 is about how to manage the already-expanding universe of such keys.

Rows
Columns

[GH-ISSUE #1114] Store rule config in editorconfig compatible files #2459