Follow-up from the second review of #92 (branch simplify-html-native-emphasis).
isMarkdownPunctuation in MarkdownRendering.kt (used by closePendingInline) treats every Unicode punctuation and symbol char as punctuation. The parser's flanking check (isFlankPunct in MarkanywhereParser.kt) only counts ASCII punctuation. So when a closer ends in ASCII punctuation and is followed by a non-ASCII punctuation char, the renderer decides the closer is right-flanking and doesn't encode the next char. The parser disagrees.
Repro
<strong>Price:</strong>€5 renders **Price:**€5, which re-parses as **Price:\*\*€5**.<strong>Note:</strong>“x” has the same problem.
Fix
Use the parser's ASCII rule in closePendingInline: skip the &#…; encoding only for whitespace or ASCII punctuation. Add a MarkdownRenderingTest case and an EmphasisDelimiterRoundTripTest fixpoint case.
Follow-up from the second review of #92 (branch
simplify-html-native-emphasis).isMarkdownPunctuationinMarkdownRendering.kt(used byclosePendingInline) treats every Unicode punctuation and symbol char as punctuation. The parser's flanking check (isFlankPunctinMarkanywhereParser.kt) only counts ASCII punctuation. So when a closer ends in ASCII punctuation and is followed by a non-ASCII punctuation char, the renderer decides the closer is right-flanking and doesn't encode the next char. The parser disagrees.Repro
<strong>Price:</strong>€5renders**Price:**€5, which re-parses as**Price:\*\*€5**.<strong>Note:</strong>“x”has the same problem.Fix
Use the parser's ASCII rule in
closePendingInline: skip the&#…;encoding only for whitespace or ASCII punctuation. Add aMarkdownRenderingTestcase and anEmphasisDelimiterRoundTripTestfixpoint case.