Emphasis inside Strong broken in JS implementation when parenthesis involved

**Nicolas_Cadilhac** · November 12, 2014, 7:39pm

Why does the following markdown string:

**Gomphocarpus (*Gomphocarpus physocarpus*, syn. *Asclepias physocarpa*)**

produces:

Gomphocarpus (Gomphocarpus physocarpus, syn. Asclepias physocarpa)**

i.e.

<p><em><em>Gomphocarpus (</em>Gomphocarpus physocarpus</em>, syn. <em>Asclepias physocarpa</em>)**</p>

I experience this in the Try page of this site and on my own web site where I installed the prebuilt JS parser. Strangely, it is well formatted in the Preview pane at the right of the box where I typed this message… (same on stackoverflow, so I guess that a different parser is used here for the preview of WMD).

**Knagis** · November 12, 2014, 7:27pm

It is because of rule 3 for the emphasis parsing:

3. A single * character can close emphasis iff it is not preceded by whitespace.

This rule probably should be extended to consider opening parenthesis - if there isn’t a good example not to?

**Nicolas_Cadilhac** · November 12, 2014, 7:28pm

You’re right. Thanks.
It would be great to include parenthesis. Writing my sentence as I did seemed so natural (and this is the right way to write in botany).

May I add a non related question?.. Is the source of this WMD editor available somewhere? Like here and on StackOverflow, I’m looking to be able to plug my image upload service.

**jgm** · November 12, 2014, 8:06pm

Yes, it’s probably a good idea to extend the rules so that closers can’t be preceded by ( (or [ or {?) and openers can’t be followed by ) (or ] or }?). Does anyone see problems with this?

Of course, it would mean you’d need to write

 *`)`*

if you wanted an italicized parenthesis.

**jgm** · November 12, 2014, 8:11pm

By the way, you can work around this for now by using _ for the inner emphasis markers.

**Nicolas_Cadilhac** · November 12, 2014, 8:17pm

but I’m still in dev process right now so this is not a hurry…

**Knagis** · November 18, 2014, 3:32pm

@jgm - There could be a better approach for handling cases such as this - skip all symbols and punctuation before checking for whitespace before or after the emphasis char.

This would also handle cases like:

foo*. bar -- only closer because followed by space (skipping the dot)
**foo "*bar*" foo** -- skips quotes

**jgm** · November 18, 2014, 8:30pm

There are some good ideas here. It looks hairy, but if I understand correctly, basic idea is fairly simple:

Strings of * or _ are divided into “left flanking” and “right flanking,” based on two things: the character immediately before them and the character immediately after.
Left-flanking delimiters can open emphasis, right flanking can close, and non-flanking delimiters are just regular text.
A delimiter is left-flanking if the character to the left has a lower rank than the character to the right, according to the following ranking: spaces and newlines are 0, punctuation (unicode categories Pc, Pd, Ps, Pe, Pi, Pf, Po, Sc, Sk, Sm or So) is 1, the rest 2. And similarly a delimiter is right-flanking if the character to the left has a higher rank than the character to the right.

**jgm** · November 18, 2014, 9:46pm

@Knagis, your idea is also a good one, I just wanted to mention another alternative that might be worth looking into. Both require recognizing unicode punctuation, which adds another level of complexity to the C parser. And your suggestion might require indefinite lookbehind or lookahead in cases where you have a whole pile of punctuation characters before or after the delimiter.

**jgm** · December 15, 2014, 2:31am

I’ve implemented a solution on the newemph branch – still need to update the spec and the JS parser. But the examples in this thread are now handled well. If anyone is intersted, the commit is here:

github.com/commonmark/CommonMark

Implement subtler rules for emphasis near punctuation in C parser.

Background:
http://talk.commonmark.org/t/emphasis-inside-strong-broken-in-js-implementation-when-parenthesis-involved/903/6

Still need to update spec and js parser.

The basic idea of the change is that if the delimiter has punctuation
to the left and a normal character (non-space, non-punctuation) to
the right, it can only be an opener.  If it has punctuation to the
right and a normal character (non-space, non-punctuation) to the left,
it can only be a closer.

This handles cases like

    **Gomphocarpus (*Gomphocarpus physocarpus*, syn. *Asclepias
    physocarpa*)**

and

    **foo "*bar*" foo**

better than before.

by jgm on 02:21AM - 15 Dec 14

changed 1 files with 10 additions and 4 deletions.

**jgm** · December 25, 2014, 6:51pm

I’ve polished this change and merged it into master. Spec, C, and JS implementations have all been updated.

% ./cmark
**Gomphocarpus (*Gomphocarpus physocarpus*, syn. *Asclepias physocarpa*)**
^D
<p><strong>Gomphocarpus (<em>Gomphocarpus physocarpus</em>, syn. <em>Asclepias physocarpa</em>)</strong></p>

**lu_zero** · December 25, 2014, 10:44pm

do you have the commit line handy? I’d sync up the python implementation later.