Markdown broken for single-character bold and italics

[jbednar]

Jupyter 5.7.2's Markdown parser seems to be unable to deal with single characters in italics, if more than two appear in any one cell. E.g. I think all of these combinations should be legal ways to specify italics, yet only a single instance, or up to two if one uses underscores and one uses asterixes, actually work:

Is there some reason this shouldn't be expected to work?

[jbednar]

I just noticed that this problem also applies to single-character bold text, which I'm sure used to work:

[laowantong]

@jbednar In the meantime, you can use ​a ZERO WIDTH SPACE (Unicode: U+200B, UTF-8: E2 80 8B).

[jbednar]

I can also use html markup, but that's not much of a fix...

[philippjfr]

Note that this problem is also present in JupyterLab. So my guess is that the JS library used to perform the Markdown rendering (i.e. probably CodeMirror?!) is responsible and is used across both notebook implementations.

[jbednar]

It looks like rendering of single characters was fine for notebook versions up to 5.3.1:

In notebook 5.4.1 and 5.5.0, bold and italics worked fine with asterixes, but italics with underscores stopped working at all for single characters (and also for two-character words, not shown here):

The current behavior started in notebook 5.6.0 and remains an issue with notebook 5.7.2:

[philippjfr]

Given your version info I suspect the regression occurred when upgrading to marked 0.4 in this PR: #3686

[cems2]

It appears to me the problem is just related to single characters!!
GUESS: It looks like it has to do with incorrect greedy regex that is parsing this internally.

the problem occurs when two different occurences of italics occur in a single line like this
**x** some text in the middle **y** some text

What happens is that the first ** before the x is treated as the italics-open mark, and the very last ** after the y is treated as the close-italics markdown. And everything in the middle including the other**marks is just treated as raw text to be italicized.

You can work around this by using __y__ instead of **y**.

it looks exactly like what you would get for a regex that was doing this:
\*\*(+*)\*\*
which will extract everything between the first and last ** it finds. Since regex is greedy it will match the longest rather than shortest next match.

to fix this, alter the regex syntax to match the shortest next match not the longest next match (the defualt).

[jbednar]

You can work around this by using __y__ instead of **y**.

I don't think that works in general, when there are several single-digit bold or italic characters in the same cell. The only workaround I've found is to insert a bogus space character into the definition, as in __x __, and then omitting the trailing space. That renders fine, though of course it makes the Markdown source unreadable and very mysterious. I'd hope that the Jupyter team can fix this before the world fills up with notebooks hacked up in this way!

[cems2]

That trick of using __X__ can be used just once only in a given paragraph then it fails. When writing math in particular there are lots of italics. As I noted the signature of this problem look exactly like a greedy regex. Thus I think the solution is to change the pattern match to a non-greedy regex ( usually this is the ? Symbol)

…

Sent from my shoePhone

On Jan 14, 2019, at 10:10 AM, James A. Bednar ***@***.***> wrote: You can work around this by using __y__ instead of **y**. I don't think that works in general, when there are several single-digit bold or italic characters in the same cell. The only workaround I've found is to insert a bogus space character into the definition, as in __x __, and then omitting the trailing space. That renders fine, though of course it makes the Markdown source unreadable and very mysterious. I'd hope that the Jupyter team can fix this before the world fills up with notebooks hacked up in this way! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[juandm]

For italics, you can workaround this issue using the LaTex inline support, just like this:

given to sets $A$ and $B$

$A$ -> A
$B$ -> B

[mick-d]

I confirm the bug

[csevast]

I confirm the bug either.

[csmyth93]

It's still buggy for me

[jwatson27]

I am running Jupyter version 5.7.8 and I am getting this error as well.

I found a workaround while we are waiting for this issue to be resolved. I am simply adding a non-printable character inside the ** ** section. For instance, to get a bold k, I use **k</t>**. Not exactly sure what this is doing, but it seems to work. If someone has more insight on this, that would be helpful.

[csmyth93]

It's still buggy for me

[jwatson27]

I am running Jupyter version 5.7.8 and I am getting this error as well.

I found a workaround while we are waiting for this issue to be resolved. I am simply adding a non-printable character inside the ** ** section. For instance, to get a bold k, I use **k</t>**. Not exactly sure what this is doing, but it seems to work. If someone has more insight on this, that would be helpful.

[gurunars]

I confirm the bug

[jasongrout]

This sounds very similar to jupyterlab/jupyterlab#5375, which we fixed in JLab by upgrading the marked package.

[Seve1995]

I'm also having the bug, Jupyter v. 5.7.8. My current workaround is to use a <span> inside the markdown, e.g. :
**x<span>**

[vanvae]

confirm the bug in Jupyter notebook 5.7.8

[oesst]

Confirming the bug in Jupyter Notebook 5.6.0

[rasbot]

This is definitely still a bug. Since this hasn't been fixed in over a year I'm assuming it won't be fixed or isn't a priority. With how many people use Jupyter Notebook, that is unfortunate.

[norvig]

Still a bug; still bugs me.

[mwermelinger]

I'm using Jupyter 6.1.4 and can't replicate the error, neither for italics nor bold.

[jbednar]

Oh thank god! I just tried it on jupyter-notebook 6.1.4 and it all appears to be working again. Happily closing this issue.

[kevin-bates]

Yes - it appears the bump to marked 0.7 via #5617 has been magical. This is consistent with Jason's #4259 (comment) and this first appeared in 6.1 (consistent with recent successes).