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.

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

GFM strikethrough compatibility #1258

Merged
merged 2 commits into from
Jul 9, 2018
Merged

GFM strikethrough compatibility #1258

merged 2 commits into from
Jul 9, 2018

Conversation

tomtheisen
Copy link

@tomtheisen tomtheisen commented May 9, 2018

Marked version: 0.3.19

Markdown flavor: GitHub Flavored Markdown

Description

This pull request brings GFM strikethrough compatibility.

Contributor

  • Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
  • no tests required for this PR.
  • If submitting new feature, it has been documented in the appropriate places.

Committer

In most cases, this should be a different person than the contributor.

  • Draft GitHub release notes have been updated.
  • CI is green (no forced merge required).
  • Merge PR

@tomtheisen
Copy link
Author

I don't think this is catastrophically backtracking regex.

Copy link
Member

@UziTech UziTech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥇

@UziTech UziTech requested a review from davisjam May 9, 2018 04:25
@@ -588,7 +588,7 @@ inline.gfm = merge({}, inline.normal, {
.replace('email', inline._email)
.getRegex(),
_backpedal: /(?:[^?!.,:;*_~()&]+|\([^)]*\)|&(?![a-zA-Z0-9]+;$)|[?!.,:;*_~)]+(?!$))+/,
del: /^~~(?=\S)([\s\S]*?\S)~~/,
del: /^~+(?=\S)([\s\S]*?\S)~+/,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Could this be simplified (no look-ahead) to /^~+([^\s~][\s\S]*?\S)~+/?
  2. Why not ~~ leading/trailing spaces ~~? Seems like the spec permits this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. The spec might allow it but github doesn't

without space:
asdf

with space:
~ asdf ~

Copy link
Contributor

@davisjam davisjam May 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Would this work? /^~+([^~]+)~+/.

(This regex will accept the "with space" version which I think is appropriate despite GitHub's treatment of it).

The spec says "No nesting" which I think means that the first ~ should terminate the strike-through.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should act like GitHub when the spec is ambiguous

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To answer my own question, /^~+([^\s~][\s\S]*?\S)~+/ won't work -- it requires a minimum of two characters between the ~s.

Copy link
Contributor

@davisjam davisjam May 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little concerned that this regex (old and new versions) will match ~~~. How about

/^~+(?=[^\s~])([^~]*[^\s~])~+/

which will:

  1. Ensure that the "text" neither begins nor ends with whitespace or a ~; and
  2. Explicitly prevent nesting without needing to rely on the non-greedy *? behavior.

Thoughts?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any particular reason to avoid the non-greedy modifier?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm nervous about the structure /~+...[\s\S]*?...~+/. I do not believe that as written the regex is vulnerable, but a slight modification would make it so. If the middle group excludes a ~ character then the risk is removed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davisjam If this is not vulnerable as written then I think we should merge it because it brings us into compliance. Adding @joshbruce to take a look.

@styfle styfle changed the title Gfm strikethrough compatibility GFM strikethrough compatibility Jul 9, 2018
@styfle
Copy link
Member

styfle commented Jul 9, 2018

Thanks Tom! 🎉

@styfle styfle merged commit c7d487e into markedjs:master Jul 9, 2018
@styfle styfle added this to the 0.5.0 - Commonmark Compliance milestone Aug 15, 2018
This was referenced Apr 6, 2020
zhenalexfan pushed a commit to zhenalexfan/MarkdownHan that referenced this pull request Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants