| Age | Commit message (Collapse) | Author |
|---|
|
Partially addresses #252.
This fixes the infinite loop, and brings the JS parser into
agreement with cmark, but both still have bad output in this
case, so more work is needed.
|
|
This improves parsing of emphasis around punctuation.
Background:
http://talk.commonmark.org/t/emphasis-inside-strong-broken-in-js-implementation-when-parenthesis-involved/903/6
The basic idea of the change is that if the delimiter is part of
a delimiter clump that has punctuation to the left and a normal
character (non-space, non-punctuation) to the right, it can only
be an opener. If it has punctuation to the right and a normal
character (non-space, non-punctuation) to the left, it can only be a closer.
This handles cases like
**Gomphocarpus (*Gomphocarpus physocarpus*, syn. *Asclepias
physocarpa*)**
and
**foo "*bar*" foo**
better than before.
The spec section on Emphasis and Strong Emphasis has been extensively
revised. The C and JS implementations have been brought up to date,
and all tests pass.
|
|
|
|
|
|
|
|
In JS, use 'Text' instead of 'Str'.
In spec, use "plain textual content" instead of "strings."
|
|
They were gobbling whitespace after shortcut reference links,
e.g.
[foo] bar
[foo]: url
Closes #214.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously there was a rule that nothing in a string of more than 3
`*` or `_` characters could close or start emphasis. This was artifical
and led to strange asymmetries, e.g. you could have
`*a *b**` emph within emph but not `**a **b****` strong within strong.
The new parsing strategy makes it easy to remove this limitation.
Spec, js, and c implementations have been updated. Spec might need
some further grooming.
|
|
It is no longer needed with the new stack-based emphasis parsing.
|
|
|
|
|
|
|
|
|
|
|
