| 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...this is a JS keyword, and at least IE8 gets confused by
it in this context.
|
|
It seems to confuse IE8.
|
|
In JS, use 'Text' instead of 'Str'.
In spec, use "plain textual content" instead of "strings."
|
|
Don't distinguish fenced, indented.
|
|
This reverts commit 4570eb2bff2e1b71fa5b6408abbc69c98ff5ff24.
|
|
This reverts commit a71423f6ee1b77d9f79d42599ea00b4ca99f5da0.
Not quite sure about this change, so reverting for now.
Note that we still have a distinction between fenced and
indented code blocks in the AST. These two distinctions
seem to stand or fall together.
|
|
Now we just have 'header' -- Setext and ATX are just two ways
of forming these; it's not a semantic difference that should remain
in the AST.
|
|
The C and JS implementations were not registering blank lines
after atx headers for purposes of tight/loose list calculation.
Exmaple:
* item
* # block1
## block2
|
|
A setext header was being treated a if it were a blank
line for purposes of tight/loose list determination.
Closes #209.
|
|
|
|
They were gobbling whitespace after shortcut reference links,
e.g.
[foo] bar
[foo]: url
Closes #214.
|
|
implementation)
When using a JS engine that provides a native String.fromCodePoint ES6 implementation (e.g. SpiderMonkey), a RangeError is thrown if the codepoint is invalid.
When adding the from-code-point.js polyfill, the js implementation was modified in order to handle invalid code point by returning the 0xFFFD placeholder glyph. So this is not a real "polyfill", but an specific implementation (adapted to the parser needs).
So, if a native String.fromCodePoint implementation is availbale, the fromCodePoint function should catch the RangeError and return the 0xFFFD placeholder glyph.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Closes #169.
|
|
|
|
It is no longer needed with the new stack-based emphasis parsing.
|
|
|
|
|
|
|
|
Modified processInlines so it creates new objects instead
of modifying in place. This way we can remove the extraneous
fields only needed for parsing.
|
|
|
|
|
|
|
|
|
|
* Moved js library code to `js/lib`.
* `js/stmd.js` is now generated from these files using browserify.
* Factored out `html5-entities.js` and `from-code-point.js` from main
js parsing code (which is now `index.js`).
* Moved `js/markdown` to `js/bin`.
|
