# I don't understand how emphasis is parsed **URL:** \ **Category:** Spec\ **Created:** [May 7, 2021, 11:49pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866 "2021-05-07T23:49:28Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Aloso](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/a/d07c76/32.png) [@Aloso](https://talk.commonmark.org/u/Aloso)\ **Post date:** [May 7, 2021, 11:49pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/1 "2021-05-07T23:49:28Z")
I wrote a Markdown implementation, and the emphasis (` **Bold** `, `*Italic*`) should follow the CommonMark specification. But while implementing it, I came across some weird edge cases where the reference implementation seems to diverge from the spec. If I just understood something wrong, can you please help me understand? When I type ` *****Hello*world**** ` in the [dingus](https://spec.commonmark.org/dingus/), the result is ```markdown

*****Helloworld***

``` But I think it should be ```markdown

**Helloworld

``` Can someone explain why that is? The spec contains this interesting rule: > 1. Emphasis begins with a delimiter that [can open emphasis](https://spec.commonmark.org/0.29/#can-open-emphasis) and ends with a delimiter that [can close emphasis](https://spec.commonmark.org/0.29/#can-close-emphasis), and that uses the same character (`_` or `*`) as the opening delimiter. In the above example, there are 5 stars on the left and 4 on the right, so the number of stars in their delimiter runs is a multiple of 3. However, neither of them can both open and close emphasis (the stars on the left can only open emphasis, and the stars on the right can only close emphasis), so the last sentence of this rule should not apply. ---
**Author:** ![mity](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mity/32/1040_2.png) [@mity](https://talk.commonmark.org/u/mity)\ **Post date:** [May 8, 2021, 8:49am UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/2 "2021-05-08T08:49:17Z")
Your interpretation breaks the rule 11: > 1. A literal `*` character cannot occur at the beginning or end of `*`-delimited emphasis or `**`-delimited strong emphasis, unless it is backslash-escaped. I.e. you have either to use all (un-escaped) `*` in the whole delimiter run for the purpose of starting or ending emphasis or strong emphasis spans, or none of them. (But you’re not alone, looking at it, my MD4C parser exhibits the same problem. There’s no example for catching this so I overlooked too.) ---
**Author:** ![mity](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mity/32/1040_2.png) [@mity](https://talk.commonmark.org/u/mity)\ **Post date:** [May 8, 2021, 8:59am UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/3 "2021-05-08T08:59:21Z")
But 2nd look shows that the specification itself provides the [example 416](https://spec.commonmark.org/0.29/#example-416) which imho breaks the rule too, so the rule is likely implemented incompletely in the cmark (maybe as of now, it guarantees it only for the opening delimiter?) Furthermore, I’m not sure whether it’s possible to implement the rules 11 and 12 without opening a door to a quadratic parsing time, because the implementation would have to implement some rollback mechanism if it eventually sees some bogus `*` or `_` would be left unused from any partially used opening or closing delimiter run and try to match the openers and closers differently. So this definitely needs some attention. @jgm? ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [May 8, 2021, 2:25pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/4 "2021-05-08T14:25:09Z")
The intended of interpreted of rule 11 is that you can’t have an unescaped `*` at the beginning or end of the text that is _inside_ `*`-delimited emphasis or strong emphasis. Sorry if that wasn’t clear enough from the wording. So for example ` **foo bar** ` can’t be interpreted as emphasized `*foo bar *` (Example 390). But Example 416 is okay because the unescaped `*`s come outside of the emphasis. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [May 8, 2021, 2:27pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/5 "2021-05-08T14:27:10Z")
In ` *****Hello*world**** ` the first delimiter run is ` ***** ` and the second is the lone `*`. Sum of the number of stars is 6, a multiple of 3, and the second one here can both open and close, so rule 9 is triggered. ---
**Author:** ![Aloso](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/a/d07c76/32.png) [@Aloso](https://talk.commonmark.org/u/Aloso)\ **Post date:** [May 8, 2021, 3:14pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/6 "2021-05-08T15:14:53Z")
I’m aware of that, that’s why `Hello` isn’t emphasized. However, `world` can be emphasized (it’s surrounded by 1 star on the left and 4 stars on the right, and 5 isn’t divisible by 3). That leaves 5 unmatched stars on the left and 3 stars on the right, which for some reason don’t emphasize the text, unless the star in the middle is removed. ---
**Author:** ![Aloso](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/a/d07c76/32.png) [@Aloso](https://talk.commonmark.org/u/Aloso)\ **Post date:** [May 8, 2021, 3:16pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/7 "2021-05-08T15:16:40Z")
> [@jgm](#): > > The intended of interpreted of rule 11 is that you can’t have an unescaped `*` at the beginning or end of the text that is _inside_ `*`-delimited emphasis or strong emphasis. That’s also how I read it, but I agree that the sentence could be phrased better to avoid confusion. ---
**Author:** ![mity](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mity/32/1040_2.png) [@mity](https://talk.commonmark.org/u/mity)\ **Post date:** [May 8, 2021, 5:24pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/8 "2021-05-08T17:24:21Z")
> The intended of interpreted of rule 11 is that you can’t have an unescaped `*` at the beginning or end of the text that is _inside_ `*`-delimited emphasis or strong emphasis. Sorry if that wasn’t clear enough from the wording. So for example ` **foo bar** ` can’t be interpreted as emphasized `*foo bar *` (Example 390). But Example 416 is okay because the unescaped `*`s come outside of the emphasis. Ok, got it but then I don’t understand the behavior. > In ` *****Hello*world**** ` the first delimiter run is ` ***** ` and the second is the lone `*`. Sum of the number of stars is 6, a multiple of 3, and the second one here can both open and close, so rule 9 is triggered. Yes, that explains why the last star from the 1st delimiter run and the star of the 2nd run do not form an emphasis of `Hello`. No mentioned parser does that. Once that is resolved, the parser then tries to use the middle star as an opener because the last delimiter has 4 stars. 4 + 1 = 5 is not divisible by 3. All the mentioned parsers follow that and produce the emphasis of `world`. However why then dingus/cmark does not try to continue using the stars of the 1st delimtier run and the 3rd delimiter run for additional emphasis/strong emphasis? The 2nd delimiter plays no role here anymore. None of the 1st and 3rd delimiter runs can be both an opener and a closer. Therefore the rule 9 should not apply anymore in this step. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [May 11, 2021, 1:22pm UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/9 "2021-05-11T13:22:46Z")
OK, I see the issue now. This does look like a bug; I’ll have to look into the algorithm to see why it’s happening. If you don’t mind putting up an issue at GitHub commonmark/cmark, that will help me keep track of it. We should probably also have a spec example like this (so maybe we also need an issue on commonmark/commonmark-spec). EDIT: just reading the algorithm at the end of the spec, I think I see the issue. We have an `openers_bottom` table that limits how far back you have to look for an opener. It is indexed to the type of delimiter (`_`, `*`) and the length of the closing delimiter mod 3. So after we fail to match the opener `*****` to `*`, we set the `openers_bottom` for `(*, 1)` to the location of `*`, effectively removing the `*****` as a possible opener for any run of `*`s with a length mod 3 of 1, including the final ` **** ` in this example. This procedure ignores the fact that the length mod 3 thing only matters if one of the delimiters can be both an opener and a closer. ---
**Author:** ![mity](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mity/32/1040_2.png) [@mity](https://talk.commonmark.org/u/mity)\ **Post date:** [May 12, 2021, 6:07am UTC](https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/10 "2021-05-12T06:07:43Z")
Filed as [Incorrect emphasis handling · Issue #383 · commonmark/cmark · GitHub](https://github.com/commonmark/cmark/issues/383) and [Incorrect emphasis handling · Issue #221 · commonmark/commonmark.js · GitHub](https://github.com/commonmark/commonmark.js/issues/221).