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

41–50 of 115 posts

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

#41

Post by masukomi »

ozim wrote: post #10

I am just getting more and more convinced that any personal todo list is useless. Most useless part is priorities on personal list. If something like utility invoice is to be paid - just do it. If it is something like "read Anna Karenina" it is not getting any priority ever it is just something I would like to do in my life. So stuff that really needs to be done I will deal with without any todo list I will just reme…

> So stuff that really needs to be done I will deal with without any todo list I will just remember it or deal with it right away.

hopefully obvious note that that simply isn't an option for anyone with ADHD.

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

#42

Post by bobbyd2323 »

I just use a big text file where I keep all notes and todos (do use a [] as well), separate dates in a structured way with most recent date at top. Typically edit it in emacs. It just keeps getting bigger and bigger, but it’s nice to have a single text file that I can search.

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

#43

Post by kstrauser »

sixstringtheory wrote: post #22
kstrauser wrote: post #13

Earlier quoted context omitted.

My problem is that I'll never remember to do those things on my own. I have repeating items for things that seem obvious but that life experience has demonstrated that I just can't track on my own. I wish I could remember to order flowers for my wife in time for them to be delivered before our anniversary, but I won't. A todo app for me is a lifesaver: instead of being all stressed out that I'm forgetting something i…

Isn't a repeating calendar event with an alert a better tool for this? But then you have to remember to check your calendar or to do the thing that alert you just snoozed/ignored was reminding you to do. Don't forget to check your todo list from time to time... I have the same problem as you, of remembering things I need to do. But I've not found todo lists to actually help, in fact I find if I take too much time to…

Some of those repeats are more flexible, like "water my plant 10 days after I last watered it". It's not going to fall over and die if I miss a day or 2. That also lets me treat my calendar as sacred: if I have an appointment there, I have to be at that place and time. My dentist won't amused if I'm a day late.

I hate recommending specific apps, but after using OmniFocus for years, I started using Things a few months ago and it's been heavenly. It's not as powerful as OF, but has all the features I actually need and not much else. I'm not tempted to waste time making my workflow absolutely perfect and optimal instead of just, you know, doing things.

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

#44

Post by 0xbadcafebee »

jotaen wrote: post #15
pessimizer wrote: post #7

No way to create subitems i.e. when the subitems are completed, the parent item is completed? The main thing I need out of a task manager is for it to allow me to decompose and refine tasks, and to keep track of that stuff as it gets complicated. If the data format doesn't even allow for subtasks, that seems impossible without abusing tags. edit: I now see that it's the top issue on your bugtracker.

For reference, this is the discussion around subitems / nesting: https://github.com/jotaen/xit/discussions/2 As mentioned in that ticket, I’m still reluctant to add this to the [x]it! file specification. On the one hand it seems like an obvious and useful feature, but on the other hand it’s unfortunately pretty difficult to implement in tooling. For example, I tried to add experimental support for nested subitems in…

I'd suggest creating a new version of the spec that requires more advanced parsing and let people add spec version to the top or bottom of the file via a comment. (adding comments would be really useful too)

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

#45

Post by kstrauser »

jen729w wrote: post #28
egypturnash wrote: post #18

Earlier quoted context omitted.

My experience is that physical to-do lists are great for sitting down, surveying what needs doing, and deciding what you’re going to do today. Including decisions like “I did not read any of Anna Karenina yesterday but I still want to do this so I am putting it on today’s list, and while I am thinking about this I took 5s to take it off the shelf and put it by the comfy reading chair”. And things like “laundry is gon…

> Digital to-do lists are where tasks go to die. I also am becoming convinced of this. The issue is that you can keep adding to them. And if you’re the digital hoarder type - hello, my friend Alex! - you can never delete the old crap. So now you have this utterly unachievable list of things that seemed like a good idea at the time. And which have lost context due to time, so now you barely even remember what you mean…

I don't even try to follow by-the-book GTD anymore, but a lot of its principles speak strongly to me. In particular, the regular review cycle is critical. It feels great to have a process in place that explicitly grants me permission to delete/cancel the things I don't want or need to do anymore. As a result, I know that my todo list has only things on it that I actually care about.

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

#46

Post by kstrauser »

jotaen wrote: post #26
kstrauser wrote: post #11

How does this compare with TaskPaper, like https://guide.taskpaper.com/getting-started/ ? TaskPaper is sophisticated enough that OmniFocus can use it as a serialization format.

I’ve never used TaskPaper, but the capabilities of the data format look somewhat similar. I think the difference is primarily a philosophical one: [x]it! is a file format with a formal specification that’s open source.[1] There is no “canonical” tool for it, the idea is rather that tools can be created separately. That should give users the freedom to work with their data independent of specific tools. [1] https://gi…

That's fair. I could've sworn that TaskPaper was an actual spec, but when looking just now I couldn't find it.

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

#48

Post by jotaen »

kstrauser wrote: post #46
jotaen wrote: post #26

Earlier quoted context omitted.

I’ve never used TaskPaper, but the capabilities of the data format look somewhat similar. I think the difference is primarily a philosophical one: [x]it! is a file format with a formal specification that’s open source.[1] There is no “canonical” tool for it, the idea is rather that tools can be created separately. That should give users the freedom to work with their data independent of specific tools. [1] https://gi…

That's fair. I could've sworn that TaskPaper was an actual spec, but when looking just now I couldn't find it.

The maintainer wrote something about this here: https://support.hogbaysoftware.com/t/where-is-taskpapers-fil...

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

#50

Post by jotaen »

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…

Thanks for sharing your notes. Nesting of items is not supported, although the idea has come up. It’s on hold right now – that’s mostly due to practical reasons, because it’s relatively hard to implement in tooling.

Allow me to clarify a few details regarding the spec:

- There can’t be any character before the checkbox. (An item “MUST start at the beginning of a line with a checkbox.”)

- A blank line is defined as “a line that is either empty, or that exclusively consists of blank characters”, and a blank character is defined as “a character from the Unicode Space Separator category (Zs)”. So the description text of an item (that can span multiple lines) cannot contain a line that’s all blank. Reason is that a blank or empty line separates item groups from each other, so allowing it to appear within descriptions could create visual ambiguity. (Even though it wouldn’t be ambiguous from a purely formal standpoint.)

- The format for dates is a subset of ISO-8601, except for the slashed variant (2020/12/31) that’s there for convenience, and the notation for quarters (2022-Q1).

Post reply on HN