Item — HN Reader

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.

1 comments

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