| Age | Commit message (Collapse) | Author | 
|---|
|  |  | 
|  |  | 
|  | 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. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Published to npm.  Closes #21.  The 'stmd' package should be
deprecated. | 
|  | 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. | 
|  |  | 
|  |  | 
|  | Serve dingus from dingus.html.
Add redirect page as index.html. | 
|  | Closes #169. | 
|  |  | 
|  |  | 
|  |  | 
|  | Changing some variable names to improve code readability | 
|  |  | 
|  |  | 
|  | 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. | 
|  |  |