Age | Commit message (Collapse) | Author |
|
|
|
Tests 390 and 391 are equal in 0.26.
|
|
for uniformity.
|
|
|
|
In light of jgm/commonmark.js#107, add a few examples/test cases to make
sure the distinction between Unicode whitespace and regular whitespace
is kept.
|
|
|
|
The definition of a list still said that "two blank lines end all
containing lists." That rule has been removed.
|
|
|
|
Fix a typo in the spec
|
|
instead of list marker spec.
|
|
This removes an ambiguity between setext headers and
lists in cases like
foo
-
|
|
|
|
|
|
This is incompatible with the principle of uniformity
(and indeed with the spec for list items, which requires
that the meaning of a chunk of lines not change when it
is put into a list item.)
|
|
|
|
Added some test cases for ATX headers and thematic breaks.
Clarified that it's not just cases that affect indentation
that matter, but all cases where whitespace matters for block
structure.
|
|
A tab ought to work; language at the beginning of the spec
will be revised to make this clear.
|
|
This reverts commit ee779cb7f8ea3c6274aef89f9916931b907e211e.
|
|
This reverts commit 5ca9ca1d5e70cbfe8eeae12f96e761c405ad8f86.
|
|
Allow HTML blocks to end on the last line of their container
|
|
This reverts commit 85bd3b9b149bef97755f16538e9c01cc386f6e5b.
|
|
This reverts commit ee75eb33f9bdf6901388e5f9175834acca814e5c.
|
|
See #410.
|
|
See discussion here: https://github.com/jgm/commonmark.js/issues/103#issuecomment-228888648
|
|
Closes #410.
|
|
|
|
See
https://talk.commonmark.org/t/emphasis-strong-emphasis-corner-cases/2123
for motivation.
This restores intuitive parsings for a number of changes.
The main change is to disallow strong or emph when one of
the delimiters is "internal" and the sum of the lengths of
the enclosing delimiter runs is a multiple of 3.
Thus,
**foo*bar***
gets parsed `<strong>foo*bar</strong>` rather than
`<em><em>foo</em>bar</em>**` as before.
|
|
Improve tests for HTML end block parsing
|
|
end tag
|
|
|
|
Added some links.
|
|
|
|
The term is actually labeled "paragraph continuation text", which
wouldn't fit in this sentence. Removing the link altogether is
consistent with other usages of "paragraph continuation line".
|
|
|
|
|
|
After implementing the changes for the 0.25 spec, all the spec tests
were green.
But I noticed that my code also counted the spaces on the first line and
required the subsequent lines to be indented accordingly. This example
catches that possible bug.
|
|
|
|
|
|
|
|
Code block with partially consumed tab.
|
|
In the blockquote with a tab following the `>`,
only one space should be consumed, yielding two
spaces at the beginning of the content.
|
|
See jgm/cmark#101
|
|
Closes #389.
|
|
|
|
|
|
|
|
The format for the spec examples has changed from
.
markdown
.
html
.
to
```````````````````````````````` example
markdown
.
html
````````````````````````````````
One advantage of this is that `spec.txt` becomes a valid
Markdown file.
`tests/spec_test.py` has been changed to use the new format.
The old `tools/makespec.py` has been replaced by a lua
program, `tools/make_spec.lua`, which uses the `lcmark` rock
(and indirectly libcmark). It can generate
html, latex, and commonmark versions of the spec.
Pandoc is no longer needed for the latex/PDF version.
And, since the new program uses the cmark API and operates
directly on the parse tree, we avoid certain bad results we
got with the regex replacements done by the python script.
|
|
|
|
Text like
Foo
bar
---
baz
is now interpreted as heading + paragraph, rather than
paragraph + thematic break + paragraph.
Existing implementations diverge quite a bit on this
case, with several interpretations:
1. paragraph, heading, paragraph
2. paragraph, break, paragraph
3. paragraph containing literal `---`
4. heading, paragraph
Interpretation 4 seems most natural, and it opens up an expressive
possibility otherwise closed off -- multiline headings.
Authors who want interpretation 2 can use a form that can't be
interpreted as a setext heading line, e.g.
Foo
bar
* * *
baz
or insert blank space around the thematic break.
Authors who want interpretation 3 can use backslash escapes.
Authors who want interpretation 1 can put a blank line
after the first paragraph.
|
|
See discussion at
http://talk.commonmark.org/t/minor-comments-and-unclarities-after-reading-the-spec/779
http://talk.commonmark.org/t/issues-to-resolve-before-1-0-release/1287/12
|