Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Incorrect emphasis handling #383

Closed
mity opened this issue May 12, 2021 · 1 comment
Closed

Incorrect emphasis handling #383

mity opened this issue May 12, 2021 · 1 comment

Comments

@mity
Copy link
Contributor

mity commented May 12, 2021

(Distilled from https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866)

Input:

*****Hello*world****

Actual Output:

<p>*****Hello<em>world</em>***</p>

Expected Output:

<p>**<em><strong>Hello<em>world</em></strong></em></p>

More detailed rationale can be found in this comment: https://talk.commonmark.org/t/i-dont-understand-how-emphasis-is-parsed/3866/8
@jgm
Copy link
Member

jgm commented Jun 15, 2021

Reading the algorithm at the end of the spec, I think I see the issue. We have an openers_bottom table that limits how far back you have to look for an opener. It is indexed to the type of delimiter (_, *) and the length of the closing delimiter mod 3. So after we fail to match the opener ***** to *, we set the openers_bottom for (*, 1) to the location of *, effectively removing the ***** as a possible opener for any run of *s with a length mod 3 of 1, including the final **** in this example. This procedure ignores the fact that the length mod 3 thing only matters if one of the delimiters can be both an opener and a closer.J

jgm added a commit that referenced this issue Jun 15, 2021
@jgm
Add failing regression test for #383.
cd26ccb
jgm added a commit that referenced this issue Jun 16, 2021
@jgm
Fix regression test for #383
ba699f9
@jgm jgm closed this as completed in dc9366c Jun 16, 2021
jgm added a commit that referenced this issue Jun 17, 2021
@jgm
A more elegant fix for #383.
ae7ead2
jgm added a commit to commonmark/commonmark-spec that referenced this issue Jun 17, 2021
@jgm
Update description of emphasis parsing algorithm in spec.
a3ab74d 
See commonmark/cmark#383.
jgm added a commit to commonmark/commonmark.js that referenced this issue Jun 17, 2021
@jgm
Fix counterpart to commonmark/cmark#383.
10ed0d0
jgm added a commit that referenced this issue Jun 19, 2021
@jgm
Revert "A more elegant fix for #383."
d5c3a34 
This reverts commit ae7ead2.
jgm added a commit that referenced this issue Jun 19, 2021
@jgm
Revert "Fix #383."
2d8a2f8 
This reverts commit dc9366c.
jgm added a commit that referenced this issue Jun 19, 2021
@jgm
More elegant fix for #383.
34250e1 
The problem arose as follows. The input was

```
*****Hello*world****
```

We have an `openers_bottom` table that limits how far back you have to
look for an opener. It is indexed to the type of delimiter (`_` or `*`)
and the length of the closing delimiter mod 3.  So after we fail to match
the opener `*****` to `*`, we set the openers_bottom for `(*, 1)` to the
location of `*`, effectively removing the `*****` as a possible opener for
any run of `*`s with a length mod 3 of 1, including the final `****` in this
example. This procedure ignores the fact that the length mod 3
restriction only matters if one of the delimiters can be both an opener
and a closer.

To fix this problem, we index the `openers_bottom` table not just to
the type of delimiter and the length of the closing delimiter mod 3,
but to whether the closing delimiter can also be an opener.
jgm added a commit to commonmark/commonmark.js that referenced this issue Jun 19, 2021
@jgm
Revert "Fix counterpart to commonmark/cmark#383."
79d7756 
This reverts commit 10ed0d0.
@snyk-bot snyk-bot mentioned this issue Jun 21, 2021
Open
rlidwka added a commit to markdown-it/markdown-it that referenced this issue Jun 30, 2021
@rlidwka
Fix emphasis algorithm as per 0.30 spec
eed156e 
commonmark/cmark#383
@snyk-bot snyk-bot mentioned this issue Jul 16, 2021
Open
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Feb 11, 2022
@depressed-pho
Import commonmark-0.2.1.1
310c35d 
0.2.1.1
* Fix bug in prettyShow for SourceRange (#80). The bug led to an infinite
  loop in certain cases.

0.2.1
* Use official 0.30 spec.txt.
* Update HTML block parser for recent spec changes.
* Fix test case from commonmark/cmark#383. We need to index the list of
  stack bottoms not just by the length mod 3 of the closer but by whether
  it can be an opener, since this goes into the calculation of whether the
  delimiters can match.

0.2
* Commonmark.Inlines: export LinkInfo(..) [API change].
* Commonmark.Inlines: export pLink [API chage].
* Comonmark.ReferenceMap: Add linkPos field to LinkInfo [API change].
* Commonmark.Tokens: normalize unicode to NFC before tokenizing
  (#57). Normalization might affect detection of flankingness, recognition
  of reference links, etc.
* Commonmark.Html: add data-prefix to non-HTML5 attributes, as pandoc does.
* Remove unnecessary build-depends.
* Use lightweight tasty-bench instead of criterion for benchmarks.
@jgm jgm mentioned this issue Nov 3, 2022
Closed
@Randyblo7 Randyblo7 mentioned this issue Aug 21, 2023
Open
@mettle-priya mettle-priya mentioned this issue Dec 6, 2023
Open
bestsoftwaretopappreviews002 added a commit to bestsoftwaretopappreviews002/commonmark-spec that referenced this issue Sep 9, 2024
@bestsoftwaretopappreviews002 @jgm
Update description of emphasis parsing algorithm in spec.
fb82e02 
See commonmark/cmark#383.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jgm @mity