-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
roundtripping emphasis in emphasis edge case changes document structure #12
Comments
Here are some more examples: a ***b*c d*
a \***b*c d*
a ***b* d*
a \***b* d* Yields (CM dingus): <p>a *<em><em>b</em>c d</em></p>
<p>a ***b<em>c d</em></p>
<p>a *<em><em>b</em> d</em></p>
<p>a *<em><em>b</em> d</em></p> so whether that escape “works” relates also to what comes after the “run”. I don’t really see an (easy) fix 🤔 |
A related edge case which can happen on the tail of emphasis next to emphasis *a*_b__ |
Hi! This was marked as ready to be worked on! Note that while this is ready to be worked on, nothing is said about priority: it may take a while for this to be solved. Is this something you can and want to work on? Team: please use the |
I came up with a way to solve this, I think: syntax-tree/unist#60 (comment). |
FYI, syntax-tree/unist#60 is solved. But, it is different than this. Most of the linked issues above are solved because of syntax-tree/unist#60. But not this issue itself. I have been thinking more and more about this, and it gets incredibly complex. *x*y z*
**x*y z*
***x*y z*
****x*y z*
*****x*y z* Yields: xy z* **xy z *xy z **xy z *****xy z Please see the points near here: https://spec.commonmark.org/0.31.2/#can-open-emphasis. There’s something at play here where, due to the different latter delimiter runs, and whether the opening run is divisible by 3, affects each other, which is changed by escaping a marker. I have no clue how to deal with such complex escaping needs, where pulling a thread somewhere, will have something happen somewhere entirely different |
Perhaps....... I will look into it later. My brain is broken. But maybe we can do this by switching markers when we have to escape a surrounding: ***x*y z*
\*_*x*y z_
***x*
\*\*_x_
*x**
_x_\*
_x__
*x*\_ These each generate the same HTML |
Subject of the issue
is stringified as:
which changes the structure
Your environment
Steps to reproduce
parse
which has the structure
and stringify it:
the resulting markdown has a different structure than the original
📓 comparing how the two pieces of markdown text are being parsed with https://spec.commonmark.org/dingus it appears in both cases it is parsed as expected.
Expected behavior
structure is the same
Actual behavior
structure is different
The text was updated successfully, but these errors were encountered: