xit

Per specification, [x]it! files must be UTF-8 encoded. (See https://github.com/jotaen/xit/blob/main/Specification.md#fil...) You can use Unicode characters in item descriptions, so you can write these texts in Japanese, Finnish, or Greek. Only the “syntactical elements” (like checkboxes, priority, due dates) are made up from ASCII characters, to ensure that they are easy to type.

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://github.com/jotaen/xit/blob/main/Specification.md

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 the Sublime Text plugin, but I eventually had to give up, just because the syntax highlighting engine is so limited in regards to recursion. It’s the same – or much worse – for other editors. At the end of the day, I feel that it doesn’t help to add such a feature to the file format, if tools then cannot deal with it properly. Right now, the spec is so simple that it can be implemented in maybe a day or so. I see a great deal

Creator here. [x]it! was deliberately designed as a strict data format that stands on its own, as I think this makes it easier to create tooling and work with the data programmatically. However, I think use-cases and preferences are as different as the people who use them, so [x]it! doesn’t aim to be the one-size-fits-all approach. For reference, there was also some discussion about this topic going on here https://github.com/jotaen/xit/discussions/10.

Nesting is currently being worked on https://github.com/jotaen/xit/discussions/2, as there are some questions to be figured out first. (Note that the [x]it! specification is a working draft right now, it’s not supposed to be final yet.)

I didn’t include nesting in the first edition of the draft, because there might be some implications with it and I was curious for feedback on this. https://github.com/jotaen/xit/discussions/2 But it seems like my potential concerns are not shared that much, so I think the nesting should be added to the [x]it! spec.

> do you plan support for text unrelated to tasks ? I haven’t thought about that much yet. I’ve tracked it here for it to be discussed: https://github.com/jotaen/xit/discussions/10 > do you plan support for sections / nested sections? I think that would be cool and useful, but I need to play around with that more. There is already a ticket for it: https://github.com/jotaen/xit/discussions/2 > idea suggestion: in tax (linked above) we use markdown bold to notify "focused" tasks and sections I think that’s similar to the priorities: [ ] !!! Do this

This is very cool, thanks for sharing! I'm a huge proponent of tool-less things, and a consistent todo list format readable in any text editor has been extremely helpful for me. I use my own markdown-inspired todo+notes format, but looking through xit and todo.txt has given me some ideas, specifically around my format's[1] inability to indicate priority when a line is taken out of context. Question: why must the square brackets be used[2]? Could not the first and third chars be omitted, leaving only the status of the item as the first char on the line? I can see (and appreciate!) the desire to use brackets for readability, but if there's a functional benefit I'm not sure I see it at first glance. I especially like your use of `!` and `#`, that's a nice way to make those items accessible through a grep. [1]: Each day begins with a `\n# YYY

I also thought about this, but I have postponed it for now, because there are some implications with this (see here: https://github.com/jotaen/xit/discussions/2). So I thought it’s better to properly think this through beforehand.

Clickable links: Website with demo: https://xit.jotaen.net File specification: https://github.com/jotaen/xit/blob/main/Specification.md

After having cycled through various CLI-based todo apps, I started to realise that I actually don’t need a tool at all for managing my todos. Most of the time, my use cases are quite simple, like viewing my todo items, checking them off, or adding a new one. Rather than having to memorise CLI commands for these interactions (which I’m not super good at), I figured that it’s easier for me to use my text editor directly, and have an editor plugin help me with the visual structure and some convenience functionality. So, kind-of similar to Emacs Org Mode, but without having to use Emacs. I personally use Sublime Text, and even though I enjoy it a lot, I don’t like being bound to specific tools. I think the best basis for staying independent is to have a data format that’s properly specified and meaningful on its own. This puts the data first,