Age | Commit message (Collapse) | Author |
|
|
|
- Removed recursion in scan_to_closing_backticks
- Added an array of pointers to potential backtick closers
to subject
- This array is used to avoid traversing the subject again
when we've already seen all the potential backtick closers.
- Added a max bound of 1000 for backtick code span delimiters.
- This helps with pathological cases like:
x
x `
x ``
x ```
x ````
...
Thanks to Martin Mitáš for identifying the problem and for
discussion of solutions.
|
|
Closes #163, thanks to @kainjow.
|
|
|
|
Otherwise we get errors in older versions of cmake.
|
|
See #162.
|
|
|
|
3.6.2) (#162)
This lets us build swift-cmark on Windows, using clang-cl
This was an oversight: CMAKE_C_VISIBILITY_PRESET is only available on CMAKE 1.8 or greater. However, the current check doesn't work for a version such as CMAKE 3.6.2, for example
```bash
mkdir "C:/Users/hughb/Documents/GitHub/my-swift/build/Ninja-DebugAssert/cmark-windows-amd64"
pushd "C:/Users/hughb/Documents/GitHub/my-swift/build/Ninja-DebugAssert/cmark-windows-amd64"
cmake -G Ninja -DCMAKE_C_COMPILER="C:/Program Files/LLVM/msbuild-bin/cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/msbuild-bin/cl.exe" -DCMAKE_CXX_FLAGS="-Xclang -std=c++14" "C:/Users/hughb/Documents/GitHub/my-swift/cmark"
popd
cmake --build "C:/Users/hughb/Documents/GitHub/my-swift/build/Ninja-DebugAssert/cmark-windows-amd64/" -- -j6 all
```
|
|
* Add test to illustrate issue
* Provide some test fixes
* Don't neglect CounterClockwiseContourIntegral
* Fix ~10% of cases not matching
strncmp returns 0 if the first 'len' bytes of cmark_entities[i].entity
match s; we check equal length in the first if by checking if
cmark_entities[i].entity[len] == 0, but we neglect the case where cmp ==
0 && cmark_entities[i].entity[len] != 0. This should be treated as the
same as cmp < 0, because strcmp("abc", "abcd") < 0.
* Don't depend on py3.3 in tests
|
|
|
|
|
|
- only check once for "not at end of line"
- check for null before we check for newline characters (the
previous patch would fail for NULL + CR)
See #160.
|
|
|
|
|
|
Fix memory leak in list parsing
|
|
If `parse_list_marker` returns 1, but the second part of the `&&` clause
is false, we leak `data` here.
|
|
|
|
See jgm/CommonMark#427
|
|
See jgm/commonmark.js#109
|
|
|
|
|
|
autolink scheme can contain digits
|
|
Added regression test.
|
|
|
|
Fixes strict prototypes warnings.
|
|
|
|
|
|
CMake fixes
|
|
Fixes #142.
|
|
|
|
|
|
Closes #141.
|
|
|
|
...they start with 1.
|
|
It's possible that cmark_chunk_set_cstr is called with a substring
(suffix) of the current string. Delay freeing of the chunk content
to handle this case correctly.
Fixes issue #139.
|
|
|
|
|
|
This allows using them in other cmake projects.
|
|
|
|
|
|
This will need corresponding spec changes.
The change is this: when considering matches between an interior
delimiter run (one that can open and can close) and another delimiter
run, we require that the sum of the lengths of the two delimiter
runs mod 3 is not 0.
Thus, for example, in
*a**b*
1 23 4
delimiter 1 cannot match 2, since the sum of the lengths of
the first delimiter run (1) and the second (1,2) == 3.
Thus we get `<em>a**b</em>` instead of `<em>a</em><em>b</em>`.
This gives better behavior on things like
*a**b**c*
which previously got parsed as
<em>a</em><em>b</em><em>c</em>
and now would be parsed as
<em>a<strong>b</strong>c</em>
With this change we get four spec test failures, but in each
case the output seems more "intuitive":
```
Example 386 (lines 6490-6494) Emphasis and strong emphasis
*foo**bar**baz*
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em>foo</em><em>bar</em><em>baz</em></p>
+<p><em>foo<strong>bar</strong>baz</em></p>
Example 389 (lines 6518-6522) Emphasis and strong emphasis
*foo**bar***
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em>foo</em><em>bar</em>**</p>
+<p><em>foo<strong>bar</strong></em></p>
Example 401 (lines 6620-6624) Emphasis and strong emphasis
**foo*bar*baz**
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em><em>foo</em>bar</em>baz**</p>
+<p><strong>foo<em>bar</em>baz</strong></p>
Example 442 (lines 6944-6948) Emphasis and strong emphasis
**foo*bar**
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em><em>foo</em>bar</em>*</p>
+<p><strong>foo*bar</strong></p>
```
|
|
It is no longer needed; only the brackets struct needs it.
Thanks to @robinst.
|
|
This is too strict, as it prevents the use of dynamically
loaded extensions: see
https://github.com/jgm/cmark/pull/123#discussion_r67231518.
Documented in man page and public header that one should use the same
memory allocator for every node in a tree.
|
|
See https://github.com/jgm/commonmark.js/pull/101
This uses a separate stack for brackets, instead of
putting them on the delimiter stack. This avoids the
need for looking through the delimiter stack for the next
bracket.
It also avoids a shortcut reference lookup when the reference
text contains brackets.
The change dramatically improved performance on the nested links
pathological test for commonmark.js. It has a smaller but measurable
effect here.
|
|
This reverts commit c069cb55bcadfd0f45890d846ff412b3c892eb87.
|
|
We reuse the parser for reference labels, instead
of just assuming that a slice of the link text
will be a valid reference label. (It might contain
interior brackets, for example.)
|
|
|
|
|
|
|
|
|