starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-25 17:26:22 +03:00

[GH-ISSUE #627] Add an option allowed_languages to the fenced-code-language #2330

New issue

Closed

opened 2026-03-07 20:06:45 +03:00 by kerem · 8 comments

kerem commented

2026-03-07 20:06:45 +03:00

Owner

Originally created by @regseb on GitHub (Nov 4, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/627

Add an option allowed_languages to the fenced-code-language rule to define the allowed languages. With this option, markdownlint will be able to check:

name consistency (javascript / js);
case (html / HTML);
typos (markdown / markdonw)
unsupported languages (json / jfather).

Originally created by @regseb on GitHub (Nov 4, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/627 Add an option _allowed_languages_ to the [_fenced-code-language_](https://github.com/DavidAnson/markdownlint/blob/a6489ac/doc/Rules.md#md040) rule to define the allowed languages. With this option, `markdownlint` will be able to check: - name consistency (`javascript` / `js`); - case (`html` / `HTML`); - typos (`markdown` / `markdonw`) - unsupported languages (`json` / `jfather`).

kerem

2026-03-07 20:06:45 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-07 20:06:46 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 4, 2022):

I think this has already been done for the next version here: github.com/DavidAnson/markdownlint@01ba757d3a

@DavidAnson commented on GitHub (Nov 4, 2022): I think this has already been done for the next version here: https://github.com/DavidAnson/markdownlint/commit/01ba757d3a9288f2ccd94a6241762a943bdb85f6

kerem commented

2026-03-07 20:06:46 +03:00

Author

Owner

@regseb commented on GitHub (Nov 4, 2022):

I didn't see that there was already the #608 issue. 😞

I looked at the commit, the languages are case insensitive. You could add ignoreCase option to check case (html / HTML).

@regseb commented on GitHub (Nov 4, 2022): I didn't see that there was already the #608 issue. 😞 I looked at the commit, the languages are case insensitive. You could add `ignoreCase` option to check case (`html` / `HTML`).

kerem commented

2026-03-07 20:06:46 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 4, 2022):

Since the new feature hasn't gone out yet, what do you folks think about making it case sensitive? If someone really wants to be able to use HTML and html, they could always add both to the allow list.

@DavidAnson commented on GitHub (Nov 4, 2022): Since the new feature hasn't gone out yet, what do you folks think about making it case sensitive? If someone really wants to be able to use HTML and html, they could always add both to the allow list.

kerem commented

2026-03-07 20:06:46 +03:00

Author

Owner

@regseb commented on GitHub (Nov 5, 2022):

It's better if the rule is case sensitive because it has more possibilities.

@regseb commented on GitHub (Nov 5, 2022): It's better if the rule is case sensitive because it has more possibilities.

kerem commented

2026-03-07 20:06:47 +03:00

Author

Owner

@nschonni commented on GitHub (Nov 5, 2022):

I think the default of case sensitivity makes sense, but I like the idea of ignoreCase. I don't think I'd see people wanting to put all permutations of the casing if there is a large code base. Either they'll want just one style + plus a list, or just a list, but "I don't care if you camelCase it or whatever" approach

@nschonni commented on GitHub (Nov 5, 2022): I think the default of case sensitivity makes sense, but I like the idea of `ignoreCase`. I don't think I'd see people wanting to put all permutations of the casing if there is a large code base. Either they'll want just one style + plus a list, or just a list, but "I don't care if you camelCase it or whatever" approach

kerem commented

2026-03-07 20:06:47 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 5, 2022):

My thinking is to except the PR to make this case sensitive by default and then wait to see if there are really people who want to allow a mix of case and aren't willing to specify which ones. Does anyone really want HtMl?

@DavidAnson commented on GitHub (Nov 5, 2022): My thinking is to except the PR to make this case sensitive by default and then wait to see if there are really people who want to allow a mix of case and aren't willing to specify which ones. Does anyone really want HtMl?

kerem commented

2026-03-07 20:06:47 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 5, 2022):

*accept

@DavidAnson commented on GitHub (Nov 5, 2022): *accept

kerem commented

2026-03-07 20:06:47 +03:00

Author

Owner

@nschonni commented on GitHub (Nov 5, 2022):

I think skipping the ignoreCase might be an easy sell, if the casing would be fixable based on the allowed values. That would probably add a bunch of complication though

@nschonni commented on GitHub (Nov 5, 2022): I think skipping the `ignoreCase` might be an easy sell, if the casing would be fixable based on the allowed values. That would probably add a bunch of complication though