| Commit message (Collapse) | Author | Files | Lines | ||
|---|---|---|---|---|---|
| 2025-01-27 | basic tests for unordered list items | 2 | -1/+31 | ||
| 2025-01-27 | update documentation | 1 | -12/+12 | ||
| 2025-01-27 | fix spurious newlines | 3 | -4/+20 | ||
| 2025-01-27 | expand starts and continues by adding current node as argument | 5 | -80/+91 | ||
| This simplifies the parser at the expense of moving the `add-new-node!` declaration into the `starts` procedure. This allows for the procedure to mutate the node when needed, which is needed for properly parsing pandoc-style grid tables. | |||||
| 2025-01-26 | indented code block test | 3 | -14/+81 | ||
| 2025-01-26 | partial suppor for ATX headings | 4 | -8/+102 | ||
| 2025-01-26 | fix tight nesting of block quotes | 5 | -10/+61 | ||
| 2025-01-26 | parsing tests | 3 | -1/+150 | ||
| 2025-01-26 | remove unordered list containers | 7 | -70/+52 | ||
| Although it is possible to incorporate automatic detection of list containers in the block parser (look ahead for `* `, if not check for ` `), but I think that this is premature. The point of the block parser is to take the input and figure out what block the item is in. All a list container does is compress together adjacent list items. This can be done in a second pass. (This might have the effect of causing list items separated by line breaks to be in the same list. If there is nothing in between, it would make sense.) | |||||
