Summary
Strong emphasis (bold) is not rendered when a ** closing delimiter is
immediately preceded by a closing bracket (e.g. ), ], ") and followed
by a non-punctuation, non-whitespace character such as a letter or digit.
Reproduction
Verified on GitHub.com via the Markdown API:
curl -s -X POST \
-H "Content-Type: application/json" \
-d '{"text": "**)**a\n", "mode": "gfm"}' \
https://api.github.com/markdown
# => <p>**)**a</p> ← not bold
| Input |
Expected |
Actual |
**)**a |
**)**a (bold) |
**)**a (literal) |
**)**1 |
**)**1 (bold) |
**)**1 (literal) |
**]**a |
**]**a (bold) |
**]**a (literal) |
**"**a |
**"**a (bold) |
**"**a (literal) |
**)**! |
)! (bold) |
✅ correct |
**)** a |
)·a (bold) |
✅ correct (with space) |
Root Cause
The CommonMark spec §6.2 defines a right-flanking delimiter run as:
(1) not preceded by Unicode whitespace, and
(2a) not preceded by a Unicode punctuation character, OR
(2b) preceded by a Unicode punctuation character AND followed by
Unicode whitespace or a Unicode punctuation character.
For **)**a, the closing ** has:
before = ) → unicode.IsPunct = trueafter = a → neither whitespace nor punctuation
Applying the rule:
!false && (!true || false || false) = false
→ The closing ** is not right-flanking → bold is not rendered.
Why this is a spec issue
Closing brackets (Unicode category Pe: ), ], }, ", », etc.)
are punctuation by Unicode definition, yet they are semantically
word-terminating — the character following them is logically separate
from the bracketed content. The current rule treats them the same as
opening punctuation like ( or ", which causes the asymmetry:
**(note)** is bold ✅ (after = space)
**(note)**. is bold ✅ (after = punctuation)
**(note)**a is NOT ❌ (after = letter)
This is counterintuitive: a user writing see **(RFC 9110)**section 5
would reasonably expect bold to apply.
Suggested fix
Amend condition (2b) to exclude closing punctuation (Unicode category Pe)
from the "preceded by punctuation" restriction:
(2b) preceded by a Unicode punctuation character other than a closing
bracket (category Pe), AND followed by Unicode whitespace or
a Unicode punctuation character.
Or equivalently: treat Unicode Pe characters as non-punctuation for the
purpose of the right-flanking delimiter rule only.
References
Summary
Strong emphasis (bold) is not rendered when a
**closing delimiter isimmediately preceded by a closing bracket (e.g.
),],") and followedby a non-punctuation, non-whitespace character such as a letter or digit.
Reproduction
Verified on GitHub.com via the Markdown API:
**)**a**)**a(literal)**)**1**)**1(literal)**]**a**]**a(literal)**"**a**"**a(literal)**)**!**)**a·a (bold)Root Cause
The CommonMark spec §6.2 defines a right-flanking delimiter run as:
For
**)**a, the closing**has:before=)→unicode.IsPunct= trueafter=a→ neither whitespace nor punctuationApplying the rule:
!false && (!true || false || false)= false→ The closing
**is not right-flanking → bold is not rendered.Why this is a spec issue
Closing brackets (Unicode category
Pe:),],},",», etc.)are punctuation by Unicode definition, yet they are semantically
word-terminating — the character following them is logically separate
from the bracketed content. The current rule treats them the same as
opening punctuation like
(or", which causes the asymmetry:This is counterintuitive: a user writing
see **(RFC 9110)**section 5would reasonably expect bold to apply.
Suggested fix
Amend condition (2b) to exclude closing punctuation (Unicode category
Pe)from the "preceded by punctuation" restriction:
Or equivalently: treat Unicode
Pecharacters as non-punctuation for thepurpose of the right-flanking delimiter rule only.
References