Age | Commit message (Collapse) | Author |
|
See jgm/commonmark.js#60.
|
|
This makes sure that implementations skip columns instead of offsets for
continued indented code blocks.
Background: I was implementing the new tab logic and was surprised that
all the spec tests passed even though I hadn't changed the continuation
logic of indented code blocks to skip columns. The added example checks
this.
|
|
It's already listed in alphabetical order on the next line.
|
|
|
|
|
|
|
|
|
|
|
|
Intent is to avoid problems with overflows.
See
http://talk.commonmark.org/t/what-is-or-what-should-be-the-range-of-indices-of-ordered-list-items/1249
Some browsers use signed 32-bit integers for indexing
the items of an ordered list, and this can lead to odd
or undefined behavior if 10-digit start numbers are allowed.
|
|
Added description of emphasis/link parsing algorithm.
|
|
This, together with previous changes in HTML block spec,
closes #239.
|
|
|
|
Not just end of the document. (Parallel to fenced code blocks.)
|
|
Insides weren't escaped properly.
|
|
|
|
Rectify omission of line tabulation, U+000B.
Closes #343.
|
|
Closes #346.
|
|
Closes #347.
Thanks for pointing this out.
We might want to revisit the decision to allow a list to
interrupt a paragraph. It's a minority opinion:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=Text+text%0A-+one%0A-+two%0A
And, in fact, in our initial discussions I was pretty strongly
opposed to it. Others felt strongly that people would naturally
create lists this way, and that it should be allowed. Some of
this is sumarized here:
http://talk.commonmark.org/t/requiring-a-blank-line-between-a-paragraph-and-list/657
The thread is a bit noisy but the point that sways me most is here:
http://talk.commonmark.org/t/requiring-a-blank-line-between-a-paragraph-and-list/657/13?u=jgm
|
|
|
|
|
|
|
|
Rename "non-space" to "non-whitespace"
|
|
|
|
See issue #337
|
|
Instead of having a preprocessing step where tabs are
converted to spaces, we now handle tabs directly in
the parser.
This allows tabs to be retained in code blocks and code
spans.
This commit adds some general language to the effect that,
for purposes of determining block structure, tabs are to
be treated just like equivalent spaces.
Much more work is needed on the spec regarding spaces and tabs,
but this change (and corresponding changes to the implementations)
is a start.
|
|
Specify nested link definition behavior in prose
|
|
This tests for the issue that's fixed in jgm/commonmark.js#49.
|
|
See jgm/commonmark.js#45.
|
|
Put entity tests on several lines for readability.
See jgm/commonmark.js#47.
|
|
The behavior was already specified in examples 426, 427, 428, 440, 441; this change merely describes it in the textual part.
|
|
|
|
|
|
Added examples.
|
|
|
|
|
|
Previously a non-space character was defined as anything but
a space (U+0020). Now it is anything that is not a whitespace
character (as defined in the spec).
|
|
|
|
|
|
|
|
Closes #322.
Added example.
|
|
Closes #323.
|
|
Previously we said that NULL must be replaced or stripped,
but this was too vague, and stripping might be a security
risk in itself.
|
|
Closes #326.
|
|
(Not an ATX header.)
|
|
This tests the problem illustrated in commonmark.js#42 and
http://talk.commonmark.org/t/odd-list-behaviour/1189
Currently both reference implementations fail this test.
|
|
|
|
|
|
See #317.
|
|
Previously this was not counted as emphasis
_(bar)_.
because the closing delimiter is both left- and right- flanking.
This fix allows such delimiters, provided they're followed
by punctuation (= they have punctuation on both sides).
Similarly, mutatis mutandis, for opening delimiters and for `__`.
Closes #317.
|
|
Say explicitly that the beginning and end of line
count as whitespace for purposes of this definition.
Otherwise the opener in `_foo_` is both left and right
flanking, as @jmendeth pointed out.
Closes #310.
|