Item — HN Reader

I’ve tried to implement the item nesting in the [x]it! Sublime Text plugin. The problem there was that I didn’t manage to implement strict rules for subitems. If you consider the following example:

    [x] Example item
        [ ] Subitem
                [ ] Another Sub-Sub Item
    Continuation of the first item’s description

Some problems I encountered:

- The “Another Sub-Sub Item” should not be allowed, because it skips one level (from the first to the third, instead of to the second).

- The “Continuation of the first item’s description” should not be allowed, because it only makes sense for sub-items to appear after an item’s description, but not in between.

- It also doesn’t seem to be possible for sub-items to inherit their parent’s status, e.g. if the parent is checked, to also colour the sub-item as if it was checked.

1 comments

Oh, interesting. When you put it that way---"Example item" and "Continuation ..." being the same semantic unit---I see the problem. And why nesting is easier to implement when the semantics are based on lines.

I think it's also interesting the way you say "The “Another Sub-Sub Item” should not be allowed". Seems to me the format and tooling should do what the user wants and expects, or at least try to. Why not allow it if the user wants it that way?

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.

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