A plain-text file format for todos and check lists
github.com
github.com
. 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 is delayed/deferred, waiting until later time
Z Task is sleeping, waiting for some dependency
I also tend to code year/month after the symbol like 2022/08 (not shown in the listed examples)By keeping a single char in the first line, I can easily grep and sort tasks to make sense of things. I know it's very crude, but it works well for my purposes. I welcome any suggestions or improvements
(edit: formatting)
- 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 textThis.
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 and search for 2 underscores and start right off.
Works everywhere.
Paper on the wall is better in many ways (e.g. easy to rip off when guests are coming over, folds into the pocket to take it with you for shopping, scan it, etc)
I use plain text files for longer term tasks and todos. One file per project.
- 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 blank lines (properly indented) would be useful for longer descriptions
- date should support an ISO or other standard date format
- timezone is necessary for events happening in specific timezones or across timezonesThat's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points.
> - doesn't support nested lists
If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more files for elaboration. Your file system is at your dispense. Additionally, that can be implemented in your plugin of choice. Goes with your first point in hand.
> - specifies a specific space character when a character class would be better
ASCII has no official character class. If your are refering to tabs; I don't think this is bad or good. Maybe you can follow uo on the use case..
> - not clear what "item must not contain blank lines" means
Probably that a blank line is used as a separator
> - description indentation limit of four space characters is a problem for nested items
I don't see why. The fixed amout of four characters obviously lines up to the start of the text from an item. This helps readability a lot. And is a simple standard for identation rules.
> - description supporting blank lines (properly indented) would be useful for longer descriptions
I disagree. A TODO list should be simple to grasp. Details and elaborations can be put in a dedicated directoy and refered to. Also, it is a _very bad_ idea to work with invisible lines. Users are dump and quick to judge.
> - date should support an ISO or other standard date format
This is the most portable standard, but extended for human editing..
> - timezone is necessary for events happening in specific timezones or across timezones
I tend to agree. But the person hosting the list should probably be the one defining the time zone. But I haven't read anythinf about time zones in the primer. Nothing stops one to simply append it to a time. No need for the standard to define such.
I think it is well put and the first one which checks all the boxes for me. Congratz to the author.
I don't see why such a comment is #1.
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.
This run-time-option-only approach would be much better than the "be liberal in what you accept and strict in what you emit" philosophy that tends to cause fragmentation on lots of different levels.
Please don't. The equivalent in programming languages would be localizing the syntactic elements ({}, (), [], '.', etc). Its much simpler for a language ecosystem to have the same syntax regardless of the programmer's language.
As far as I know, international keyboards can still type these characters just fine.
There are languages written from right to left or top to bottom. No standard I know of are supporting such flexibility in syntax. And it shouldnt be necessary - if the <user text> items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....
"mother or preferred"
-- I don't disagree with your basic point, but I like to be included :). There's a Lot of us around whose native / mother tongue is not English, but we prefer it for computing tasks (and frequently gaming / movies / entertainment too - Forums are littered with folks complaining of having to "enjoy" a horrible localized version of something, instead of the original English)
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).
Why wouldn't you allow space before the checkbox? If somebody accidentally has a space because it's not obvious in their editor (esp. if items can be separated by two newlines) what happens? Undefined behavior? Your format looks a lot like Markdown so I wouldn't have assumed this was a spec requirement unless I looked closely (most people don't look at specs closely)
[x]it! is supposed to be edited (editable) by hand, and from an end-user perspective, I personally find ISO-8601 in its entirety relatively complex to grasp. The currently supported date formats aim to be a tradeoff between “flexible enough” but “not too complex yet”.
> Why wouldn't you allow space before the checkbox?
To enforce a tidy layout of the file. Whitespace before the checkbox (i.e. on the same line) is undefined behaviour. The idea is that editor plugins help users with compliance of the rules. For example, I think that all available [x]it! editor plugins would highlight it if there was illegal whitespace in front of a checkbox.
For vim, I just use vim-wiki, which is a superset of this functionality.
Of course, looking through this thread, there's lots of different options. Which is cool.
https://github.com/coezbek/rodo
Differences:
I use unicode symbols such as ⌛ or for paused or priority items.
I use dash for obsolete/canceled items. I find this more in line with bullet journal which inspired the development of Rodo.
I do use markdown bullet lists because I like to indent and order stuff.
Rodo is organized primarily around showing the todos of a day (mostly today) and provides the tools to postpone or carry-over todays to another day.
[x]it! doesn’t try to be opinionated about what you use it for. So you could use it for your daily todos, but you could also use it for writing a packing list, or maintaining a wish list with potential shopping items. It’s intended to be a generic file format, and more specific use-cases could be supported through (independent) tooling.
The creator made a few videos on the motivation & implementation of it. He goes into such great detail in crafting subtle almost unnoticable animations in the app.
- https://www.youtube.com/watch?v=kZdBgVZn5NI - https://www.youtube.com/watch?v=JjKxpks13Zw
I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).
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 just recreate the file and sync it back to all other devices. And when I tried it, it didn't support links to org-IDs.
If you want a plain text organizational, compositional and scheduling tool that you can use for the rest of your life and know that 30 years down the line it will be actively supported, developed and you will be able to tweak anything you want.... emacs/org mode is by far and away the best choice. It isn't even remotely close, we are talking about the difference between a planet and a tiny asteroid when you compare org mode to other plain textish organizational, compositional and scheduling tools.
For as long as humanity doesn't collapse and probably even after it does org mode and emacs will be used (there is going to be some nerd somewhere using org mode and ledger cli to meticulously track how many smoked rats and cockroach kebobs they have left to eat before they have to leave their bunker), there is just such an intense critical mass of utility under an open source license.
About the only bad thing with org mode at this point is it has such a vast nexus of interconnected capability it is difficult to even describe what exactly it is anymore lol. Like how would you even adequately describe org mode in a single sentence? It would have to be a Thomas Pynchon style sentence lol.
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
I built two apps for iOS:
There are other org-based tools out there.
Outside... of emacs? You leave emacs?
It's a fine standard.
edit: I now see that it's the top issue on your bugtracker.
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 of value in keeping the hurdle for tool creators small. But it’s a pretty tricky balancing act in the end.
[ ] Check you can log into Jenkins
[ ] Check you have an account on lab1
[ ] SSH into account on lab1
[ ] "mkdir bin"
[ ] "mkdir conf"
[ ] "mkdir var"
[ ] In shell configuration file, export following
[ ] export FOOBAR=...
[ ] export PATH=$PATH:$FOOBAR/bin:$FOOBAR/install
[ ] export LD_LIBRARY_PATH=$FOOBAR/lib64b:$LD_LIBRARY_PATH
[ ] Ensure you can run "sudo -u root foo"
[ ] Ensure you can run "sudo -u nobody bar"
[ ] Check you have an account on lab 2
[ ] SSH into account on lab2
[ ] ...
A second section outlining the steps needed to prepare to run the regression test. The third section was actually running the regression test, and the final section about shutting down the regression test. This list was then checked into our repository and any new hires were given this check list to do (and update it for any steps not clear or not specified---such updates happened a few times).When I came up with this system, I didn't know about ORG mode. Nor did I expect anyone to use a tool other than a text editor with this. Heck, a person could print this out and use a pen to mark items off the list.
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
[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.
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
(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.
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.To me, the convention to go with seems easy.
1) If the parent is explicitly checked, leave the children as they are, and ask the user through tooling if they want to check each unchecked subtask, delete it, or move it up a level.
2) If all of the children are checked, the parent stays unchecked, but tooling should ask the user if the parent is complete, or if another subtask should be added.
3) If the parent has a closer due date than the children, don't do anything unless you feel like warning the user i.e. hold the subtasks to their due dates, and hold the parent task to its due date.
The issue about descriptions I see as a non-issue: dictate that descriptions marry to the task above them. It would be nicer to be freer with mixing descriptions and tasks, but you'd have to introduce more tokens.
One thing in the thread that I don't find necessary is marking partial completion.
I don't have any experience with Sublime, but this seems like a very basic tree.
When reading the subtasks, all you have to hold is the stack of the checkbox states and due dates of higher task levels for tooling to answer any of the above questions. A tool could seek backwards in order to check a parent if the children were checked, the user was warned, and the user said they wanted the parent checked. But if instead you really only wanted to read a line at a time, you could add a dummy item called "[ ] Complete parent task" at the end of the subtask list in order to keep an unchecked parent with checked children consistent.
The problem for me is that a tree is what I have trouble organizing. If it's just a linear list of things, I'm not sure how useful it could be for me other than by setting alarms that I could set directly. There is never a time when one of my tasks isn't to break down another task into simpler steps; all but the simplest tasks I have really have "break this down" that as the default first subtask.
So one workflow datapoint for useful with subtasks, useless without subtasks.
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.
If you also assign specific icons per extension, which you can do e.g in Total commander, you have a nice icon-coded todo list.
Using files instead of lines has several advantages. E.g. you can add notes in an item. Copy paste/link across projects etc. Search items vs in-text. Use dotfiles or ignore-patterns to hide/unhide items, associate certain tasks with specific apps (e.g. calendar) ... etc etc.
Have been using this for more than a decade, works great.
[1] https://github.com/aziz/PlainTasks [2] https://www.linux-magazine.com/Online/Blogs/Productivity-Sau...
::ProjectA
---
@@@Things to do
@@@Sub-tasks
@@Things to do, but not right away* Things done
::ProjectB
---
@@@Another thing
Easy to search for things like:
"@@@" for the current TODO (and also show it in the menu bar with SwiftBar)
"::ProjectName" to look for projects
"* " to keep in a date-stamped file. I have kept such files since 2009.
gist that preserves formatting: https://gist.github.com/hboon/2684da05fe6c5d7afbcbaa4d847824...
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 remember it or deal with it right away.
Stuff that does not need to be done will not get done - and that is perfectly fine.
Different thing is if it is company "todo" list and I need to keep customer requests, well JIRA does the job.
In the end don't listen to me because there are many much more successful people than me, I am simply happy with what I achieved so far, maybe I would achieve more with todo lists but somehow I fail to see how these would help me in living my life.
Just remember. That's exactly the thing I (for example) am not capable of. I keep forgetting everything. Every time I have some spare time, I am checking my todo first if there's something I need/want/can do.
It is also why I am writing comments on the internet, to see what are other people life experiences.
Digital to-do lists are where tasks go to die.
I just keep on coming back to a nice notebook, a nice pen, and my variant of the Pomodoro method.
But yeah, not accumulating stuff requires a conscious decision and the will to stick to it. The same goes for paper, though. I have a coworker that at some point had a stack of paper over 20 cm high.
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 meant.
I introduced Alex to Things.app’s feature whereby you can mark a task as ‘Cancelled’. So it takes it off the list, but you’re not pretending that you did it. I hope that helps him.
Me, I use slips of paper and a pencil. On my desk the slips closest to me are those that I’m doing, or should do, now. When there’s too much paper, it’s obvious. Throwing away (by sticking it on the spike) a piece of paper feels good. It’s just a piece of paper.
Well you're lucky then, because I frequently have to remind people of important things they (still) have to do and seem to have forgotten. Having such a list is a way to avoid the stressful situation of being late with things you can't postpone or which you benefit greatly from doing sooner rather than later.
Additionally, some todo's have different timeframes than others. I try to think of things as short term/immediate, medium term/this week, and long term/nextweek-before I die.
I'll occasionally pick things of the long term list and cut them down into an action I could do immediate or this week, for example, get Anna karenina from the library.
hopefully obvious note that that simply isn't an option for anyone with ADHD.
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 maintain the list, I have less time to spend doing the things I'm supposed to do.
Kind of like remembering phone numbers. I don't know anyone's phone number anymore, because I don't have to, because I have a place that I can store them all. The difference is that the phone dials it for me when I tap it; my todo list doesn't carry out the tasks I write on it, but it does help me to forget them faster!
It's some mixture of https://xkcd.com/1906/, https://xkcd.com/927/ and https://xkcd.com/1319/
That's how my mind works, YMMV.
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.
My biggest problem earlier was that I thought I should have a todo list to achieve things in life. As it turns out it just does not matter, my connections, my starting point in life was much more defining to what I can achieve today than any form of organization of my self I would implement.
Of course unless I would be totally undisciplined and disorganized, but it turns out that I was disciplined and organized enough to reach good life and adding todo list is not something that would help me.
Deleted comment
That's a separate problem, and a good reason to have periodic reviews. If you have big items that stay on your list for weeks you should consider removing them or make them more actionable than they currently are.
But anyway, one convention I picked up from there is:
- for a comment - something to remind yourself of the context or information to remember
. for a task you want to do
date . for a task that needs to be done on/by a certain date
/ for a task that is started
X for a completed task
> for a task that moved to a later page
It's a great system especially as transition from one state to another is just the addition of a line so very easy to do with pen and paper. Also, the act of transferring uncompleted tasks to a new page every week/month depending on preference makes it a great time to assess if things on the todo list are still worth doing as well as giving you a gentle reminder to get on and do them if they are.For reference, there was also some discussion about this topic going on here https://github.com/jotaen/xit/discussions/10.
It's optional, so I'd assume it's for people who want to start the sentence from same aligned column.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
Isn't 2022-08-23 the standard format; ISO 8601?
Yes, visual alignment is the first purpose; the other is if you want to sort your lines lexically (as described elsewhere in this discussion), then the dots enable deterministic ordering, because exclamation marks sort before dots.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
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).
`====== MORNING ERRANDS ======`
Is it good at indented text wrapping?
Not sure what you mean by the text wrapping bit, but I think that appropriate/pleasant text wrapping would be a concern of an editor.
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 క్ రి [minus the space, HN turned by ZWNJ into a space :/] instead of క్రి), letter ra, vowel sign i, letter sa, sign virama (which this time just suppresses the inherent vowel). Six code points, of which three are Other_Letter (part of Letter) and three Nonspacing_Mark (part of Mark, not Letter).
Unicode’s Letter general category is almost never what you want. To begin with, you should instead use the “Alphabetic” property, which examination of https://www.unicode.org/reports/tr44/#Alphabetic and https://www.unicode.org/reports/tr44/#GC_Values_Table shows to be a superset of Letter, adding the Letter_Number (Nl) general category and the Other_Lowercase, Other_Uppercase and Other_Alphabetic properties.
But actually, even Alphabetic isn’t quite the right tool: some scripts don’t separate words with non-alphabetical characters, and some scripts use non-alphabetical characters in the middle of words (e.g. ZWJ and ZWNJ in Indic texts, or apostrophes in English). For most correct results, I believe you actually need to get into full text segmentation to find word breaks, as defined in UAX #29 <https://www.unicode.org/reports/tr29/>.
As usual: language is fiendishly complicated.
The other definitions are a strange mixture. Digit is ASCII-only, which makes sense for due date, but is inconsistent with Unicode letters elsewhere.
> The tag name MUST only contain letters, digits, or the characters _ or -. It MUST be treated as case-insensitive.
This is somewhat poorly defined, and I’m confident that from such a definition you’ll get multiple incompatible implementations. I would say that you probably want to specify something based on Unicode’s caseless matching; see https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#G217... which will give you much to read and despair of ever understanding. (The whole two and a bit pages of that subsection are worth reading. And I wouldn’t complain if you decided it was worth reading a lot more of the Unicode spec.)
But in this place, I don’t think you actually want letters/digits/_/- anyway. I think that for tag names you’d do better with using UAX #31 <https://www.unicode.org/reports/tr31/> identifiers of some form. Note its optional medial characters (how you’d add -), its “hashtag identifiers”, and its remarks on case folding.
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.
Seriously though, this looks great.