What does it mean by "must not be a multiple of 3" phrase in the emphasis section of CommonMark Spec?

Spec
1

I had asked this question on Stack Overflow, but I couldn’t get a proper answer. Can you help me? Here is the whole text:

In the emphasis and strong emphasis section of CommonMark Spec, it says:

  1. Emphasis begins with a delimiter that can open emphasis and ends with a delimiter that can close emphasis, and that uses the same character (_ or *) as the opening delimiter. The opening and closing delimiters must belong to separate delimiter runs. If one of the delimiters can both open and close emphasis, then the sum of the lengths of the delimiter runs containing the opening and closing delimiters must not be a multiple of 3.

But I have no idea what it means by “the sum of the lengths of the delimiter runs containing the opening and closing delimiters.”

  1. What is it, and why it must not be a multiple of 3?
  2. What happens if it is a multiple of 3?

Edit: I found the demonstration on the same website and there was a code

odd_match = (closer.can_open || opener.can_close) &&
(opener.numdelims + closer.numdelims) % 3 === 0;
if (opener.cc === closer.cc && opener.can_open && !odd_match) {
opener_found = true;
break;
}

> ([source](http://spec.commonmark.org/dingus/commonmark.js)). My rough understanding is that this rule was intended for restricting three-character delimiter runs in the middle of  alphanumeric characters. (e.g. "\*\*\*hello\*\*\*" will be rendered to be ***hello***, but "\*\*\*hello\*\*\*world" will not be rendered.) However, I'm not sure if my understanding is correct, and why such restriction is needed if I understood it correctly.
2

See the explanations at
http://spec.commonmark.org/0.27/#example-388
and https://github.com/jgm/cmark/commit/c50197bab81d7105c9c790548821b61bcb97a62a

3

There’s an explanation of the original change here:

4

Thank you for your answer. Then the purpose of the rule is to handle the ‘em-inside-strong’ (and also the ‘strong-inside-em’) cases, right? Isn’t there any simpler and more intuitive way to make those cases work properly? I mean, I think this rule is unintentionally restricting some other cases: for example, ***hello***world syntax that I have mentioned.

5

+++ queued [Apr 03 17 16:55 ]:

Thank you for your answer. Then the purpose of the rule is to handle
with the ‘em-inside-strong’ (and also the ‘strong-inside-em’) cases,
right? Isn’t there any simpler and more intuitive way to make those
cases work properly? I mean, I think this rule is unintentionally
restricting some other cases: for example, helloworld syntax that
I have mentioned.

Well, I’m certainly openminded about this, if you have a better approach to suggest. We have a fairly large corpus of cases in the test suite. If you can come up with a different algorithm, it can easily be tested against those to see if it has unintended bad results.

6

Hello !

I have the same understanding problem. Now I “know” thanks.
However, taking this case a bit further, I find this example troublesome:

**bar*** = <strong>bar</strong>*

foo**bar*** = foo<strong>bar</strong>*

*foo***bar*** = <em>foo</em>**bar***

Why the last example could not just parse as <strong> like the rest ?! Is this because of the same rule ?