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?
[x] Example item
[ ] Subitem
[ ] Another Sub-Sub Item
Continuation of the first item’s description
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.
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