-
-
Notifications
You must be signed in to change notification settings - Fork 316
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
Interior strong+emph not parsed #528
Milestone
Comments
This change in cmark does the trick: diff --git a/src/inlines.c b/src/inlines.c
index bab607a..6e92aff 100644
--- a/src/inlines.c
+++ b/src/inlines.c
@@ -642,7 +642,8 @@ static void process_emphasis(subject *subj, delimiter *stack_bottom) {
// interior closer of size 2 can't match opener of size 1
// or of size 1 can't match 2
if (!(closer->can_open || opener->can_close) ||
- ((opener->length + closer->length) % 3) != 0) {
+ closer->length % 3 == 0 ||
+ (opener->length + closer->length) % 3 != 0) {
opener_found = true;
break;
} This test should be equivalent, because if closer length is a multiple of 3 and the sum of closer and opener length is a multiple of 3, opener length has to be a multiple of 3. So we don't to test that separately. I think I'm convinced we should change the spec. |
jgm
added a commit
to commonmark/cmark
that referenced
this issue
Mar 23, 2019
both have lengths that are multiples of 3. See commonmark/commonmark-spec#528.
jgm
added a commit
to commonmark/commonmark.js
that referenced
this issue
Mar 23, 2019
are multiples of 3. See commonmark/commonmark-spec#528.
colinodell
added a commit
to thephpleague/commonmark
that referenced
this issue
Mar 24, 2019
colinodell
added a commit
to thephpleague/commonmark
that referenced
this issue
Mar 24, 2019
talum
pushed a commit
to github/cmark-gfm
that referenced
this issue
Sep 14, 2021
both have lengths that are multiples of 3. See commonmark/commonmark-spec#528.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This doesn't parse like I expect:
Because of rules 9 & 10 here it parses as just a single text run with no emphasis.
For my purposes I need that to parse as strong+emphasis, and it seems like a simple addition to the rules makes it work, namely that if both the opener and closer delimiters have a length that are a multiple of 3, then they are considered valid delimiter runs.
Here's a patch to comrak that implements such a rule while still passing the spec suite:
brson/comrak@ac3218b
cc @kivikakk
The text was updated successfully, but these errors were encountered: