Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A plain-text file format for todos and check lists

github.com

Post reply on HN
Print view View original

111–115 of 115 posts

Re: A plain-text file format for todos and check lists

#111

Post by kidsil »

Last5Digits wrote: post #94
kidsil wrote: post #93

Why not Orgmode? I've been using it on multiple devices without any problems. I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).

Have you found a good way to use org-mode on your phone? I remember trying to find a suitable app for weeks, but without any success. Even simple things, like following links into other files, were not possible. Edit: Ah, I missed you mentioning Orgzly. Last time I used it, I had a lot of trouble with syncing due to its way of storing files in a notebook. Everytime I deleted a file on any other device, Orgzly would j…

Orgzly with Syncthing has been my setup for years.

Re: A plain-text file format for todos and check lists

#112

Post by jotaen »

rmavis wrote: post #110
jotaen wrote: post #89

Earlier quoted context omitted.

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…

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…

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.

Re: A plain-text file format for todos and check lists

#113

Post by liyuankui »

Last5Digits wrote: post #94
kidsil wrote: post #93

Why not Orgmode? I've been using it on multiple devices without any problems. I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).

Have you found a good way to use org-mode on your phone? I remember trying to find a suitable app for weeks, but without any success. Even simple things, like following links into other files, were not possible. Edit: Ah, I missed you mentioning Orgzly. Last time I used it, I had a lot of trouble with syncing due to its way of storing files in a notebook. Everytime I deleted a file on any other device, Orgzly would j…

Must mention Logseq. Logseq support org-mode as first class format. https://trello.com/c/z651hP7v/1116-org-mode-support I don't think Logseq has realized how this feature can win popularity, since you can't find anything on org-mode in their website. (Always markdown, LOL)

Re: A plain-text file format for todos and check lists

#114

Post by lifehasleft »

0xbadcafebee wrote: post #39

I like it. Few issues: - doesn't describe handling spaces or other characters before the checkbox - doesn't support UTF-8 checkbox emoji - doesn't support nested lists - specifies a specific space character when a character class would be better - not clear what "item must not contain blank lines" means - description indentation limit of four space characters is a problem for nested items - description supporting bla…

Some of your comments are described in the extended syntax specifications[0].

[0]: https://xit.jotaen.net/syntax-guide

Re: A plain-text file format for todos and check lists

#115

Post by rmavis »

jotaen wrote: post #112
rmavis wrote: post #110

Earlier quoted context omitted.

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…

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 dat…

> 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.
Post reply on HN