| Age | Commit message (Collapse) | Author |
|---|
|
string_content is just for the raw string content that will be parsed
as inlines, not for the 'real' content of the block element.
|
|
|
|
|
|
|
|
Small performance improvement.
|
|
|
|
|
|
|
|
|
|
This helps with performance.
|
|
|
|
|
|
|
|
(Note: this is helping performance. We have regained everything
we lost with the last major change, and more.)
|
|
|
|
|
|
Use the same doubly linked node structure that cmark uses.
The primary advantages of this change are (a) simplified code,
especially in the renderers, and (b) elimination of the need for
recursion, so we can render deeply-nested structures without a
stack overflow.
A node walker has also been added, for easy AST traversal.
* Added js/lib/node.js for nodes. Includes a node walker.
* All modules updated to use node structures.
* Regularized position information into pos property.
* Performance is slightly worse than before, but only marginally,
and no doubt there are more optimizations that can be done.
|
|
|
|
|
|
Now we use 'children' uniformly, in both inlines and blocks,
for child nodes.
|
|
This matches the C impl.
Also removed an unused property.
|
|
Closes #267.
|
|
Closes #263. Note, this only affects inline comments.
With block comments we parse differently, and don't guarantee
that only valid HTML5 comments will pass. This all needs to
be made more explicit in the spec.
However, this fix addresses the cpu problem.
|
|
|
|
|
|
|
|
Partially addresses #252.
Still need to:
- update C parser.
- put an example in the spec.
|
|
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.
|
|
|
|
|
