Updated inline grammar regexes for strong and em

[barrywoolgar]

Description

• Fixes Incorrect parsing of emphasis around numbers? #1297 and Fixes Bold formatting in single line not properly parsed. #1306 by moving special case single character matches before the more permissive standard regexes that are causing the issues described.

Contributor

• Test(s) exist to ensure functionality and minimize regression; 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

[barrywoolgar]

I am aware I need to add/update tests to this PR before it can be merged, but I haven't the time right now to figure them out so I'm creating this PR as a placeholder for me.

If there's somewhere that describes the dev setup and testing folders (which look many and varied!) please let me know, otherwise I'll figure it over the weekend or next week.

[styfle]

Hi @barrywoolgar thanks for the PR!

The contibuting doc has some information (it assumes you have node.js installed) so that should get you going with running the test suit.

The good news is, you didn't break any existing tests so that means all that we need is a test case for each issue you linked to 👍

[UziTech]

If you fix a current spec test that is failing then all you need to do is remove it from shouldPassButFails

marked/test/specs/commonmark/commonmark-spec.js

Lines 333 to 346 in 7f311d7

	describe('CommonMark 0.28 Emphasis and strong emphasis', function() {
	var section = 'Emphasis and strong emphasis';
	// var shouldPassButFails = [];
	var shouldPassButFails = [333, 334, 342, 348, 349, 352, 353, 354, 355, 356, 360, 368, 369, 371, 372, 378, 380, 381, 382, 387, 388, 392, 393, 394, 395, 396, 402, 403, 409, 416, 419, 420, 421, 422, 423, 424, 428, 431, 432, 433, 434, 435, 436, 443, 444, 445, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458];
	var willNotBeAttemptedByCoreTeam = [];
	var ignore = shouldPassButFails.concat(willNotBeAttemptedByCoreTeam);
	cmSpec.forEach(function(spec) {
	messenger.test(spec, section, ignore);
	});
	});

https://spec.commonmark.org/0.28/#example-333

[barrywoolgar]

That's great, thanks. Will have a look when I get home in a few then!

…

On Thu, 2 Aug 2018, 20:07 Tony Brix, ***@***.***> wrote: If you fix a current spec test that is failing then all you need to do is remove it from shouldPassButFails https://github.com/markedjs/marked/blob/7f311d761bebbfb203833f50c5255511d2923736/test/specs/commonmark/commonmark-spec.js#L333-L346 https://spec.commonmark.org/0.28/#example-333 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF9WSZU1Mb6pMNzNIa86VmkPIkQHQUkaks5uM03bgaJpZM4Vswmc> .

[barrywoolgar]

Hi, thanks for the pointers. I've got the test suite running and I can't find an existing shouldPassButFails example that covers this case (all 57 existing ones continue to fail with and without the patch).

I assume I shouldn't be making changes to the commonmark spec, as that seems to reference external examples. InsteadI've added some examples (matching those reported in the issues) to /test/new/cm_strong_and_em.*.

Is this sufficient? Thanks

[styfle]

I confirmed this does fix the two issues and the new test looks good.

I'm a little surprised that it didn't pass test 333 but I tried it myself and it's still failing on this branch.

CommonMark 0.28 Emphasis and strong emphasis should pass example 333
  Message:
    CommonMark (Emphasis and strong emphasis):
    a*"foo"*
    
    ------
    
    Expected:
    <p>a*&quot;foo&quot;*</p>
    
    ------
    
    Marked:
    <p>a<em>&quot;foo&quot;</em></p>

Given that this fixes some bugs, I think it's still worth merging as-is.
@UziTech Any more thoughts on this one?

[davisjam]

Safe

[davisjam]

Safe

[davisjam]

The regexes are safe. If the tests don't break then I'm happy.

[barrywoolgar]

I've been rather taken by investigating the shouldPassButFails arrays, so if I've made some of them pass with further changes to the above lines would you like me to add more commits here or is there some way to submit a new PR without this one being merged first?

[UziTech]

If you are willing to fix some of the tests we can wait on merging the PR (best solution IMO).

Or if you want we can merge this PR and you can submit a new PR with the improvements

[UziTech]

Adding [WIP] to the beginning of the title of this PR will let us know to wait on merging it.

[barrywoolgar]

Thanks, apologies to the reviewers who will presumably need to do it all again when I'm done.

[Feder1co5oave]

+1

[davisjam]

Remove this before acceptance.

[barrywoolgar]

Yup, sorry about that. Suddenly very busy at work but will tidy up and push my progress asap.

[styfle]

Are we just waiting on removing a comment in this PR?
If so, we can merge and create a new PR to remove the comment 😄

@joshbruce I think this should be in 0.5.0 too

[barrywoolgar]

Sorry for the delay, work and personal life have got in the way a bit here. I've fixed the commented line, and pushed another commit that fixes the disabled tests for 333, 450, 452, 505, and 535.

I was making some progress on some others but I'll have to submit those under a new PR as I doubt they'll be done anytime soon now.

I have found that trying to read/debug a single regex that covers both the __ and ** formats is quite difficult, so I fell down a bit of a hole trying to separate those before continuing development.