Store rule config in editorconfig compatible files about markdownlint

[sgryphon]

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

[DavidAnson]

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.

DavidAnson/markdownlint-cli2#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

[FloEdelmann]

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

[sgryphon]

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)

[DavidAnson]

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: editorconfig/editorconfig#332