> The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on.
I get it :) and that's how I implemented mine too: https://git.sr.ht/~rfm/tdtd-parser/tree/master/item/tdtd.jan...
> However, “Subitem” doesn’t have direct child items.
I'm not sure if the difference in our approaches is philosophical or practical. Why shouldn't "Another Sub-Sub Item" be considered a direct child? What if the user added the extra spaces unintentionally? What if, just for fun, they wanted to indent their list like:
[x] Example item
[ ] Subitem
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
Continuation of the first item’s description
If that was my list, and my list's parser couldn't handle that, I wouldn't be very happy. But what would/could/should I expect the behavior to be? I'd hope, given the rule that a child has more leading whitespace than its parent, that all three Sub-Sub Items would be treated as peers.
I get it :) and that's how I implemented mine too: https://git.sr.ht/~rfm/tdtd-parser/tree/master/item/tdtd.jan...
> However, “Subitem” doesn’t have direct child items.
I'm not sure if the difference in our approaches is philosophical or practical. Why shouldn't "Another Sub-Sub Item" be considered a direct child? What if the user added the extra spaces unintentionally? What if, just for fun, they wanted to indent their list like:
If that was my list, and my list's parser couldn't handle that, I wouldn't be very happy. But what would/could/should I expect the behavior to be? I'd hope, given the rule that a child has more leading whitespace than its parent, that all three Sub-Sub Items would be treated as peers.