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.
|
|
Closes #251.
|
|
Closes #251.
|
|
Closes #108.
|
|
Factored test selection logic out of do_tests.
Eliminated do_tests, putting the (now very short) code into main.
Improves 1ba4822 @cirosantilli
|
|
Removed from .travis.yml.
This should be a standard part of the test suite.
See #245.
|
|
* The tests test for removal of whitespace around block-level tags.
* Previously whitespace wasn't removed before an initial block-level
tag; this commit fixes that.
* Also revised wording so it's clear that whitespace is removed
on both sides of block-level tags.
Closes #246 in a slightly different way.
|
|
Closes #249 in a slightly different way.
|
|
spec_tests add short options for common parameters
|
|
Add --number option to run a single test by its id
|
|
Indicate which is expected and which is actual output.
|
|
Don't raise exception on invalid UTF-8 output
|
|
This could be reproduced with:
./test/spec_tests.py --program kramdown --pattern Enti
with Kramdown version 1.5.0.
The main problem is that it would stop future tests from being carried out.
After this commit it is just counted as a failure.
The error message printed is of the form:
Unicode error: 'utf8' codec can't decode byte 0xfc in position 8: invalid start byte
'<p># \xd3\x92 \xcf\xa0 \xef\xbf\xbd</p>\n'
'<p># \xd3\x92 \xcf\xa0 \xfc\x85\xb8\xb0\xa9\xb8</p>\n'
|
|
|
|
Do not check input validity, e.g. input `>` number of tests, because
other inputs don't check it either, e.g. `--pattern`.
If given, the summary line will be like:
1 passed, 0 failed, 0 errored, 509 skipped
|
|
|
|
|
|
Expose failure to normalize whitespaces
|
|
|
|
Remove stray character
|
|
|
|
Fix links to the spec
|
|
All the links the spec were broken. I changed `http://jgm.github.io/CommonMark/spec.html` to `http://spec.commonmark.org/0.13/`. It'd be nice if there was a `http://spec.commonmark.org/latest/` so you don't need to change the README every time a new version (unless there's major changes so the URL fragments aren't valid anymore.
The spec itself has some broken fragment links, e.g. `#image` instead of `#images`. Unfortunately I don't have a good tool that checks fragments so I don't have the full list.
|
|
|
|
|
|
Remove it from the repository. Closes #241.
|
|
Ignore pyc files
|
|
They may be generated when you run the tests.
|
|
|
|
In the last few commits we were using as.code.fenced and as.literal at
the same time for NODE_CODE_BLOCK, which obviously led to problems.
|
|
|
|
|
|
Reverts 225d720.
|
|
Added a test case with a unicode nonbreaking space.
See #108, though "whitespace" should still be defined more
systematically. This is a step forward.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is for consistency with the other types of nodes that have
literal strings as contents.
|
|
For completeness.
|
|
|
|
Previously the spec said, wrongly, that a blank line was needed
between a paragraph and a following code block. It is only needed
between a code block and a following paragraph (due to lazy
continuations).
Thanks to textnut for pointing this out.
|
|
|
|
|