[GH-ISSUE #789] MD049 should not trigger when using asterisk for intraword emphasis #532

New issue

Closed

opened 2026-03-03 01:27:45 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @Josh-Cena on GitHub (Apr 24, 2023).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/789

Consider the following config (using markdownlint-cli2):

{
  "config": {
    "default": true,
    "MD049": {
      "style": "underscore"
    }
  }
}

However, MD049 triggers for the following code:

In this array, the leftmost column contains the entries *a*₁, *a*₂, *a*₃, and *a*₄.

These cases cannot be fixed to underscores, because underscores are not allowed as intraword emphasis, per CommonMark:

Many implementations have also restricted intraword emphasis to the * forms, to avoid unwanted emphasis in words containing internal underscores. (It is best practice to put these in code spans, but users often do not.)
internal emphasis: foo*bar*baz
no emphasis: foo_bar_baz

Prettier correctly handles this case by not converting the asterisks (and even actively corrects underscores to asterisks).

Originally created by @Josh-Cena on GitHub (Apr 24, 2023). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/789 Consider the following config (using markdownlint-cli2): ```json { "config": { "default": true, "MD049": { "style": "underscore" } } } ``` However, MD049 triggers for the following code: ```md In this array, the leftmost column contains the entries *a*₁, *a*₂, *a*₃, and *a*₄. ``` These cases cannot be fixed to underscores, because underscores are not allowed as intraword emphasis, per [CommonMark](https://spec.commonmark.org/0.30/#emphasis-and-strong-emphasis): > Many implementations have also restricted intraword emphasis to the `*` forms, to avoid unwanted emphasis in words containing internal underscores. (It is best practice to put these in code spans, but users often do not.) > ``` > internal emphasis: foo*bar*baz > no emphasis: foo_bar_baz > ``` [Prettier correctly handles this case by not converting the asterisks (and even actively corrects underscores to asterisks).](https://prettier.io/playground/#N4Igxg9gdgLgprEAuEBDABAfQGYQpgHSiIxz0wE6iStd9BAgmqlLs0AN5Jl8gRk9vIBGqAE5EQAGhAQADjACW0AM7JQI4RADuABREJlKVABsNqAJ7LJA4ajABrODADKqALZwAMnKhxk2I4rhLazsHR2kbLwBzZBhhAFdAkDgXATgAEzT091QoSLjUSLgAMQhhF1QYeVzkNDiYCAkQAAsYF0MAdSa5eEVwsDhHPW65ADdu0xqwRQsQLwDhGC1rSPLff0SAK0UAD0cowzgARTiIeDXDAMlw4Xma8uFbNM0oRulhLxh2uTSYJuQADgADFd1AF2tZpDU3nB5iMfJIAI4neBLGT6NCKAC03nS6UawjgSLkBKWBVWSD8F0SARcchi8Wp+zgAEFKu8BHU4Fo4MJPN5zpcQIomcdTj4KetJDBUAIvj8-kgAExS6xyQxRADCEBc5KSigArI04gEACoy-SUwUjBIASSgmVgjjA71kzPtjhgpgOArgAF9fUA)

kerem

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

closed this issue
added the
bug

fixed in next
labels

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (Apr 24, 2023):

You've told the rule that all emphasis should be done with an underscore and it is correctly reporting on instances that are using asterisk for emphasis instead.

I don't think I agree it's wrong to do so. In this case, you could switch to underscore as shown here: https://dlaa.me/markdownlint/#%25m%23%20Issue%20780%0A%0AIn%20this%20array%2C%20the%20leftmost%20column%20contains%20the%20entries%20a%E2%82%81%2C%20a%E2%82%82%2C%20a%E2%82%83%2C%20and%20a%E2%82%84.%0A%0AIn%20this%20array%2C%20the%20leftmost%20column%20contains%20the%20entries%20_a%E2%82%81_%2C%20_a%E2%82%82_%2C%20_a%E2%82%83_%2C%20and%20_a%E2%82%84_.%0A%0A%3C!--%20markdownlint-configure-file%20%7B%0A%20%20%22MD049%22%3A%20%7B%0A%20%20%20%20%22style%22%3A%20%22underscore%22%0A%20%20%7D%0A%7D%20--%3E%0A

I realize that output is subtly different, but I'm not sure this is the kind of nuance I want to try to bake into the rule implementation. Instead, I am inclined to suggest this is an edge case, and you can use an inline comment to disable the rule for this case.

@DavidAnson commented on GitHub (Apr 24, 2023): You've told the rule that all emphasis should be done with an underscore and it is correctly reporting on instances that are using asterisk for emphasis instead. I don't think I agree it's wrong to do so. In this case, you could switch to underscore as shown here: https://dlaa.me/markdownlint/#%25m%23%20Issue%20780%0A%0AIn%20this%20array%2C%20the%20leftmost%20column%20contains%20the%20entries%20*a*%E2%82%81%2C%20*a*%E2%82%82%2C%20*a*%E2%82%83%2C%20and%20*a*%E2%82%84.%0A%0AIn%20this%20array%2C%20the%20leftmost%20column%20contains%20the%20entries%20_a%E2%82%81_%2C%20_a%E2%82%82_%2C%20_a%E2%82%83_%2C%20and%20_a%E2%82%84_.%0A%0A%3C!--%20markdownlint-configure-file%20%7B%0A%20%20%22MD049%22%3A%20%7B%0A%20%20%20%20%22style%22%3A%20%22underscore%22%0A%20%20%7D%0A%7D%20--%3E%0A I realize that output is subtly different, but I'm not sure this is the kind of nuance I want to try to bake into the rule implementation. Instead, I am inclined to suggest this is an edge case, and you can use an inline comment to disable the rule for this case.

kerem commented

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

Author

Owner

@Josh-Cena commented on GitHub (Apr 24, 2023):

In this case, you could switch to underscore as shown here:

This is semantically incorrect: subscripts are number entities, which must remain upright in formulae. Also consider other cases where intraword emphasis is intentional: *J*ava*S*cript *O*bject *N*otation.

You've told the rule that all emphasis should be done with an underscore and it is correctly reporting on instances that are using asterisk for emphasis instead.

The rule reports instances where underscores should be used but asterisks are seen. But in this instance, using underscore makes it not even an emphasis anymore. When I use "underscore", I'm enforcing a style of "use underscores where I can", not "any emphasis using asterisk is automatically wrong".

It even comes with an autofixer that produces invalid output. It is my belief (from working on ESLint rules) that an autofixer should never break code, because people unconsciously run it in CI/pre-commit and then may never notice it again. Since making the autofixer conditionally available is not any less complex than making the rule report at all, maybe we should remove the autofixer if we don't want this logic in the rule?

@Josh-Cena commented on GitHub (Apr 24, 2023): > In this case, you could switch to underscore as shown here: This is semantically incorrect: subscripts are number entities, which must remain upright in formulae. Also consider other cases where intraword emphasis is intentional: `*J*ava*S*cript *O*bject *N*otation`. > You've told the rule that all emphasis should be done with an underscore and it is correctly reporting on instances that are using asterisk for emphasis instead. The rule reports instances where underscores should be used but asterisks are seen. But in this instance, using underscore makes it not even an emphasis anymore. When I use `"underscore"`, I'm enforcing a style of "use underscores where I can", not "any emphasis using asterisk is automatically wrong". It even comes with an autofixer that produces invalid output. It is my belief (from working on ESLint rules) that an autofixer should never break code, because people unconsciously run it in CI/pre-commit and then may never notice it again. Since making the autofixer conditionally available is not any less complex than making the rule report at all, maybe we should remove the autofixer if we don't want this logic in the rule?

kerem referenced this issue

2026-03-03 01:30:37 +03:00

[PR #532] [MERGED] Create FUNDING.yml to enable a sponsor button for the repository. #884

kerem referenced this issue

2026-03-07 20:10:19 +03:00

[PR #532] [MERGED] Create FUNDING.yml to enable a sponsor button for the repository. #2733