CommonMark’s flanking rules work poorly for Chinese, Japanese and Korean text. These languages don’t put spaces between words, so emphasis often ends with punctuation that is directly followed by a letter. The closing delimiter is then not right-flanking:
**该星号不会被识别，而是直接显示。**这是因为它没有被识别为强调符号。
The closing ** is preceded by 。 (punctuation) and followed by 这 (a letter), so both delimiters stay literal text.
The CJK-friendly amendments fix this by changing one condition of the flanking rules: a delimiter run next to a CJK character or CJK punctuation still counts as flanking. They are proposed for CommonMark itself in commonmark-spec#650. There are plugins for markdown-it, micromark/remark and marked, and Comrak, goldmark and Markdig implement them. VitePress and Rspress turn them on by default. Text without CJK characters parses exactly as it does under plain CommonMark.
I use @lezer/markdown for the source view of a Markdown editor whose files follow these amendments. I’d like its syntax tree to agree with them, both for highlighting and for commands that read the tree, such as toggling bold.
Replacing the Emphasis inline parser by name works, and computing the amended flanking is easy. The problem is the delimiters the replacement adds. resolveMarkers applies its emphasis logic (splitting runs by length, the rule of 3, Emphasis vs. StrongEmphasis) only to delimiters whose type is EmphasisAsterisk or EmphasisUnderscore, and those types aren’t exported. So a replacement parser can’t produce delimiters that resolve as emphasis.
For now I run a second Markdown parser over each inline section to find which delimiters pair. I then give each pair a DelimiterType of its own, with resolve: "Emphasis" or "StrongEmphasis". This works, but every inline section is parsed twice, and the second parser repeats work Lezer already does well.
Would you consider exposing the two types, the way InlineContext.linkStart and InlineContext.imageStart are exposed? For example, as InlineContext.emphasisAsterisk and InlineContext.emphasisUnderscore. A replacement parser could then be:
import {InlineContext} from "@lezer/markdown"
const CJKFriendlyEmphasis = {
parseInline: [{
name: "Emphasis",
parse(cx, next, start) {
if (next != 42 /* '*' */ && next != 95 /* '_' */) return -1
let end = start + 1
while (cx.char(end) == next) end++
let {canOpen, canClose} = cjkFriendlyFlanking(cx, start, end, next == 42)
let type = next == 42 ? InlineContext.emphasisAsterisk : InlineContext.emphasisUnderscore
return cx.addDelimiter(type, start, end, canOpen, canClose)
}
}]
}
If you’d rather support the amendments directly, as an optional extension like Strikethrough, that would work for me too.