3 ms·

I realised that I made a small mistake in my code sample above, but I can’t edit the post anymore. It should have been: [x] Example item [ ] Subite

by jotaen 4y ago

I realised that I made a small mistake in my code sample above, but I can’t edit the post anymore. It should have been: [x] Example item [ ] Subitem [ ] Another Sub-Sub Item Continuation of the first item’s description (Last line is indented, because continuations of descriptions have to be indented.) 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. However, “Subitem” doesn’t have direct child items. I find this restriction important, because it would allow to parse the text into relatively simple programmatic models.

rmavis 4y ago
> 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.janet 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.

by jotaen 4y ago

rmavis 4y ago

> 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.janet 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.