Age | Commit message (Collapse) | Author |
|
* open_new_blocks: always create child before advancing offset
* Source map
* Extent's typology
* In-depth python bindings
|
|
The `alloc` member wasn't initialized.
This also allows to add an assertion in `chunk_rtrim` which doesn't
work for alloced chunks.
|
|
|
|
|
|
|
|
1. Downloaded CaseFolding.txt from http://unicode.org/Public/UCD/latest/ucd/CaseFolding.txt
2. Deleted src/case_fold_switch.inc
3. Ran `make src/case_fold_switch.inc`
|
|
|
|
|
|
|
|
- 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.
|