Conversation
task_lists.test separates lists by bullet character but never mixes a task marker with a plain one, and writes every box lower-case. lists.test ends a list at a bullet of another kind but not at an ordered marker of another kind, so the blank line after that marker is never asked whether it loosens the list. Its ambiguous-marker cases resolve on the second item or stay ambiguous, so neither a one-item `i.` list nor an item after the second deciding is covered. The tightness cases pin two sentences of the spec -- blank lines at the end of a nested list do not count, and tightness is per list -- and that a tight item is still a container of blocks. All eight pass on main.
| ``` | ||
| - one | ||
|
|
||
| - sub | ||
| more | ||
|
|
||
| - two |
There was a problem hiding this comment.
This is a bit awkward, huh? What if you want the outer list to be loose; is there any way to force that?
There was a problem hiding this comment.
I'm not a fan of the tight/loose list distinction at the syntax level in general, since I don't really think about that when writing lists. For me it would probably be fine to just switch to loose lists when one item contains more than one paragraph. But I didn't think much about it.
So to answer your question, no I don't see a way to force a loose list here.
If you don't count the blank lines as belonging to the sublist, the current behavior contradicts the spec, which counts blank lines "between blocks inside an item" against tightness. Here the blank line between one and the sublist is exactly that. Then again, the spec's own tight example (- two / blank / - sub) has the same shape, so the spec may need clarifying either way.
| A tight item still holds blocks, so one that opens with a fence is | ||
| not a paragraph of literal text: |
There was a problem hiding this comment.
I didn't understand what was meant here.
There was a problem hiding this comment.
It came from a regression where a fenced block in a tight item was parsed as paragraph text. Without that context this reads strangely. Changed to
Items in a tight list can contain non-paragraph blocks:
| The same for an ordered list, where the blank line after `a.` is not | ||
| between two of the first list's items and does not loosen it: |
There was a problem hiding this comment.
This is a bit mysterious: since a. starts a second list, why is the first list being mentioned?
There was a problem hiding this comment.
Yes, not sure how I got there. Changed to
A blank line between two lists doesn't make either of them loose:
| </ol> | ||
| ``` | ||
|
|
||
| That holds for a list of one item too: |
There was a problem hiding this comment.
I cut a less relevant test case before and forgot to update the description in this one that referred to it. Changed to
A lone
i.could be roman 1 or alphabetic 9. Roman wins:
2 participants
task_lists.test separates lists by bullet character but never mixes a task marker with a plain one, and writes every box lower-case. lists.test ends a list at a bullet of another kind but not at an ordered marker of another kind, so the blank line after that marker is never asked whether it loosens the list. Its ambiguous-marker cases resolve on the second item or stay ambiguous, so neither a one-item
i.list nor an item after the second deciding is covered.The tightness cases pin two sentences of the spec -- blank lines at the end of a nested list do not count, and tightness is per list -- and that a tight item is still a container of blocks.
As with most of my test cases, these are cases an LLM got wrong when implementing a djot->HTML converter. Just let me know when you think the cases get too niche and bloat the test suite. I have a backlog of potentially upstreamable cases and only collect a few of them for a PR from time to time.