Age | Commit message (Collapse) | Author |
|
Use $(MAKE) in Makefile for recursive makes
|
|
|
|
On some system namely OpenBSD/FreeBSD GNU Make is called gmake and
calling make directly from the Makefile leads to strange results.
See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
|
|
|
|
|
|
|
|
|
|
CMake fixes
|
|
Fixes #142.
|
|
link fix
|
|
|
|
|
|
|
|
|
|
Closes #141.
|
|
|
|
|
|
|
|
|
|
...they start with 1.
|
|
instead of going through all the formats and options
and probably getting the same output.
|
|
Fix chunk_set_cstr with suffix of current string
|
|
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.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reduce the storage size for the `cmark_code` struct
|
|
|