Live data from Hacker News

A plain-text file format for todos and check lists

github.com

81–90 of 115 posts

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

#81
post #15

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…

It's mostly the lack of nesting that convinced me not to use xit and to make my own format: http://richardmavis.info/does-the-world-really-need-another-...

And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md

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

#82
post #78

I like it and have used a similar homegrown solution for years. I’d love to switch to a better supported one, but please: work in progress is obviously […] Not ... but the actual … character which takes the same horizontal space as X on monospaced fonts. Maybe use it as a second option? Nice work, thanks for sharing.

That character is not directly on keyboards, so it requires additional, OS-specific knowledge to type it.

I don’t know. That’s a very common character.

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

#85

I like that specification. I've used something similar for many years. I code my task list into a text file using a single character to show status: . This is a pending/idle task item, and normal priority _ Task is pending/idle, and low priority (the "someday" tasks) ! This is a pending/idle task item, and high priority (fix today/soon) * Currently working on this item # Task was completed X Task was cancelled > Task…

With [x]it!, lexicographic sorting of lines works as well, as long as you stick to the following rules:

- Write due dates first (if you use due dates)

- Pad your priority with dots (if you use priorities)

- Don’t use line breaks within descriptions, so only single-line items

- Don’t use titles

That way, the lines will sort by checkbox status (open first), then by priority (highest first), and finally by due date (soonest first). For example:

    [ ] !!! -> 2022-05-01 Something
    [ ] ..! -> 2022-06-15 Something else
    [x] .!! -> 2022-01-04 More text

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

#86

> Letter: a character from the Unicode Letter category (L) This definition is insufficient for many scripts, such as Indic scripts. My name “Chris” is written in Telugu as “క్రిస్”: letter ka, sign virama (which suppresses the inherent vowel, and also joins the next letter and vowel sign as a conjunct in this instance, as part of the same syllable—if you didn’t want that, you’d insert a ZERO-WIDTH NON-JOINER and get…

Thanks for your detailed notes, I’ll look through your links.

Just to clarify for context, the “letter” definition is only relevant for tags, so outside of #tags (in item descriptions, or group titles) you can use any Unicode character you want.

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

#87
post #76

Nice. Supports emoji's? Looks like the UTF-8 is not yet supported directly.

[x]it! files are UTF-8 encoded by default. The predefined syntactical elements (such as checkboxes, priorities, or due dates) are composed from ASCII characters, but outside of that (e.g. in item descriptions) you can use all available Unicode characters without restriction.

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

#88

I like it and have used a similar homegrown solution for years. I’d love to switch to a better supported one, but please: work in progress is obviously […] Not ... but the actual … character which takes the same horizontal space as X on monospaced fonts. Maybe use it as a second option? Nice work, thanks for sharing.

Thanks for your feedback. I think for the status characters there are a lot of imaginable variations and preferences. In the end, I thought that restricting the spec to a single character per status would help to confine the overall complexity of the file format, so it’s a bit of a tradeoff.

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

#89
post #81
post #15

Earlier quoted context omitted.

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…

It's mostly the lack of nesting that convinced me not to use xit and to make my own format: http://richardmavis.info/does-the-world-really-need-another-... And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md

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.

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

#90

I like that specification. I've used something similar for many years. I code my task list into a text file using a single character to show status: . This is a pending/idle task item, and normal priority _ Task is pending/idle, and low priority (the "someday" tasks) ! This is a pending/idle task item, and high priority (fix today/soon) * Currently working on this item # Task was completed X Task was cancelled > Task…

> grep and sort tasks to make sense of things This. grep + sort + awk = unbelievable single person task management effectiveness. And it was right under my nose all the while. I've dumbed my version even further, I just use numbers. every line starting with 1 is highest Priority and so on. another important piece i needed was a pointer to where i last left off. I just use double underscores "__". next time just open…

Doug McIlroy recounts how early use of egrep for personal calendars led to Al Aho improving its algorithm: https://minnie.tuhs.org/pipermail/tuhs/2022-August/026336.ht...
Post reply on HN