Fix newlines consistency, list item trims and overriding list rendering #27
Conversation
The newlines for blocks, like paragraphs/code/blockquote/table,
are now consistent; one before and one after.
Other fixes:
* Remove space before list items
* Change default tab size to 4 spaces
* Change how lists are rendered/overriden by options
* Change 'listitem' option to only affect individual items rather
than a whole list
* Add 'list' option for overriding the bullets/numbering behaviour
* Support nested lists
* Fix newline differences between ul's and ol's
* Add end to end test, which is a document of full markdown syntax
Possible issues:
Newline at the beginning of output becomes a weird requirement...
A 'block' should have a newline before and after. To achieve this,
we can do that literally, or apply a two newlines before or after;
ideally a two newlines after, to avoid a newline at the start of
the rendered output.
This opportunity breaks down, however, because of how lists are
rendered ontop of each other recursively. They require a newline
before their individual outputs as to avoid rendering into the
same line between list nest levels.
|
Also #hacktoberfest because I want that free shirt, Mmmmm! |
|
Oh. How have I not seen that hacktoberfest is an actual organized thing before now. I've seen it mentioned several placed, but never looked into it. August/September/October are traditionally very hectic times for me, so probably for the better I didn't get another thing to try to achieve 😛 |
|
Dat free shirt tho 😻 |
|
Awesome work @loklaan! I tried some of my presentation appears as on Which also seems incorrect. I'd expect it to render just the input (an ordered list with an unordered sublist). |
|
Great catch @noffle! Fixed and added tests. |
|
Back from a conference! I'll remind myself to check this out tonight. |
|
So, looking into this, the prefixed newline for it is due to all I'm very skeptical of the leading whitespace, I must say. |
|
I'd prefer to have a double newline after the sections, but then nested lists would break. They require a newline before their individual outputs as to avoid rendering into the same line between list nest levels. Because there isn't (correct me if I am wrong) a way for the blocks to know about the previously rendered block, achieving consistency means accommodating the lowest denominator (nested list support) with a single approach. |
| } | ||
|
|
||
| function section (text) { | ||
| return '\n' + text + '\n'; |
There was a problem hiding this comment.
If you change this to return text + '\n\n'; you will see that everything works, the newline at the start of output is gone, but nested lists's first item will be merged into the last item of it's parent list.
In doing this, a fix for the first nested list point needs to be applied to all lists.
|
OK 👏 Leading newline has been removed. I think the PR is ready ready. |
|
Great work! Looking good. 👏 🎉 |
|
Since the output looks different, in terms of newlines/whitespace, should this be a major or minor? |
|
Really unsure about this, if the output is a part of the API or not, but I guess there's no reason not to do a major release. |
|
There's also breaking changes in the |
|
New version out: 2.0.0 |
Hello again,
Following things were fixed, and that could mean this is a major semver change:
listitemis still just a chalk resetlist(new option) takes thefunction (body, ordered)signature. it is responsible for attaching points onto list itemI've introduced a weird padding behaviour; there will always be a newline at the start of the output.
I needed to introduce it to make consistent vertical padding AND make sure that nested lists work. I don't really want it there, but couldn't think of a way to get rid of it.
I'll need you to weigh in with this, concerning the newline-at-the-start-of-output and also how these changes may require a major semver change due to how old expected behaviours have changed.