| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It's the core of the program and I had too much trouble making
sense of it, two loops with many cases and other code
interspersed hurt my head.
All the tests still passed before rebasing, now I've got the
exact same set of issues as master.
|
|
|
|
|
|
|
|
|
|
E.g. in
```
- foo
<TAB><TAB>bar
```
we should consume two spaces from the second tab,
including two spaces in the code block.
|
|
This keeps track of when we have gotten partway
through a tab when consuming initial indentation.
|
|
Closes #101.
This patch fixes `S_advance_offset` so that it doesn't gobble
a tab character when advancing less than the width of a tab.
|
|
|
|
|
|
|
|
API change. Sorry, but this is the time to break things,
before 1.0 is released. This matches the recent changes to
CommonMark.dtd.
|
|
Ultimately I think we can get rid of parser->curline and
avoid an unnecessary allocation per line.
|
|
CMARK_NODE_HRULE -> CMARK_NODE_THEMATIC_BREAK.
However we've defined the former as the latter to keep
backwards compatibility.
See jgm/CommonMark 8fa94cb460f5e516b0e57adca33f50a669d51f6c
|
|
Defined CMARK_NODE_HEADER to CMARK_NODE_HEADING to ease
the transition.
|
|
See jgm/CommonMark commit 0cdbcee4e840abd0ac7db93797b2b75ca4104314
Note that we have defined
cmark_node_get_header_level = cmark_node_get_heading_level
and
cmark_node_set_header_level = camrk_node_set_heading_level
for backwards compatibility in the API.
|
|
|
|
|
|
This previously caused cmark to break out of a list,
thinking it had two consecutive blanks.
|
|
|
|
So `S_process_line` sees only unix style line endings.
Closes #72, avoiding mixed line endings.
Ultimately we probably want a better solution, allowing
the line ending style of the input file to be preserved.
This solution forces output with newlines.
|
|
Closes #71.
Added a test to api_test.
|
|
|
|
See jgm/CommonMark#332
|
|
* Reformatted all source files.
* Added 'format' target to Makefile.
* Removed 'astyle' target.
* Updated .editorconfig.
|
|
|
|
|
|
This should be added to the spec.
|
|
(It uses GNU extensions, and we don't need it anyway.)
|
|
* Rewrote spec for HTML blocks. A few other spec examples
also changed as a result.
* Removed old `html_block_tag` scanner. Added new
`html_block_start` and `html_block_start_7`, as well
as `html_block_end_n` for n = 1-5.
* Rewrote block parser for new HTML block spec.
|
|
|
|
This caused certain NULLs not to be replaced.
Found my 'make fuzztest'.
|
|
Also command line option `--validate-utf8`.
This option causes cmark to check for valid UTF-8,
replacing invalid sequences with the replacement
character, U+FFFD.
Reinstated api tests for utf8.
|
|
|
|
We now replace null characters in the line splitting code.
|
|
Now it just replaces bad UTF-8 sequences and NULLs.
This restores benchmarks to near their previous levels.
|
|
We no longer preprocess tabs to spaces before parsing.
Instead, we keep track of both the byte offset and
the (virtual) column as we parse block starts.
This allows us to handle tabs without converting
to spaces first. Tabs are left as tabs in the output.
Added `column` and `first_nonspace_column` fields to `parser`.
Added utility function to advance the offset, computing
the virtual column too.
Note that we don't need to deal with UTF-8 here at all.
Only ASCII occurs in block starts.
Significant performance improvement due to the fact that
we're not doing UTF-8 validation -- though we might want
to add that back in.
|
|
|
|
This isn't actually needed.
|
|
Guard against too large chunks passed via the API.
|
|
There are probably a couple of places I missed. But this will only
be a problem if we use a 64-bit bufsize_t at some point. Then, we'll
get warnings from -Wshorten-64-to-32.
|
|
|
|
Added fields `offset`, `first_nonspace`, `indent`, and `blank`
to `cmark_parser` struct.
This just removes some repetition in the code.
|
|
|
|
This fixes cases like:
```
1. a
2. b
3. c
```
|
|
|
|
From btrask's alternate code in the comment on
https://github.com/jgm/cmark/pull/18.
Note: this gives a 1-2% performance boot in our benchmark,
probably enough to make it worth while.
|
|
Conflicts:
src/blocks.c
|
|
Closes #52.
|
