fixinfo if identical errors on the same line #2248

New issue

Closed

opened 2026-03-07 20:05:59 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @Billiam on GitHub (Jan 19, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/486

Example:

**a** __b__ __b__

The above will generate two errors for inconsistent strong style for the two __b__ elements, but both errors will share the same range and fixinfo, pointing to only the first instance.

Obviously markdown-it doesn't provide this information with the token, and that range info comes from helpers.getRangeAndFixInfoIfFound, which just uses indexOf against the markdown line. This works fine as long as the elements don't have identical content like above.

Instead, I think getRangeAndFixInfoIfFound could accept an offset or instance number instead of only returning info for the first result.

I assume this affects other inline checks but I'm not sure which offhand.

Originally created by @Billiam on GitHub (Jan 19, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/486 Example: ```markdown **a** __b__ __b__ ``` The above will generate two errors for inconsistent strong style for the two `__b__` elements, but both errors will share the same range and fixinfo, pointing to only the first instance. Obviously markdown-it doesn't provide this information with the token, and that range info comes from `helpers.getRangeAndFixInfoIfFound`, which just uses `indexOf` against the markdown line. This works fine as long as the elements don't have identical content like above. Instead, I think `getRangeAndFixInfoIfFound` could accept an offset or instance number instead of only returning info for the first result. I assume this affects other inline checks but I'm not sure which offhand.

kerem

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

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (Jan 19, 2022):

Agree, but I expect this is unlikely in practice. And if it does come up, the next iteration will fix that second violation.

@DavidAnson commented on GitHub (Jan 19, 2022): Agree, but I expect this is unlikely in practice. And if it does come up, the next iteration will fix that second violation.