|
FormatProposal
Proposed format for todo.txt files
Introductiontodo.txt files are an easy way to keep track of your projects and todo lists. The text format allows ultimate portability and the ability to edit in whatever way suits you best. Here is an overview of some possible extensions to the original format. The following elements should be able to appear in any order. Parsers may however change the order to be consistent - eg. tags and contexts always at the end. Projects / TagsProjects or tags provide a method of tagging a task with memorable keywords. The original todotxt.com projects used one of several formats:
The p:project notation has issues when using bash completion since : is a special character for the shell. The +project format is recommended. A task can have several tags to allow improved searching. Many sites have started implementing tagging of data. However, tags are encouraged but should remain optional. +home +code +todo add information to the wiki ContextsContexts are a label to indicate in what context or situation the task should be carried out. For example - a search for @email or @phone allows all tasks that can be done whilst near a phone to be listed simultaneously. Contexts are normally specified using the @context format. Several contexts should be allowed per task. Contexts are encouraged but remain optional. @phone billy bob about bolts and bits PriorityTasks can be given a priority based on their importance and desired order of action. Priorities are indicated using a (A), (B), (C), (X) notation at the start of a line. (A) this is an important task task bodyThe remainder of the task message that describes what actually needs to be done. This should be a single 'crankable widget'. Preferably one that can be done without thinking too much! a task with nothing but a body is missing out Done StateTasks that have been completed are indicated as being 'done' using a simple 'x ' at the start of a line. The addition of a date after the 'x ' will be supported but should be depricated or a method for adding time information established. See Date Attributes below. x this is a done task x 2006-10-06 this doesn't give time information x 2006-10-06_15:45_PST this might work but is a little non-standard ExtensionsAttributesAttributes can be any named option enclosed in curley braces in the following format: {attribute : value} Spaces between the colons should be optional but spaces in the attribute or value are allowed. Multiple attributes can be added per line. Attributes should always be optional. Display of attributes should be optional to reduce clutter. Date AttributesDates are extended in the form {name: date}. Where name is one of:
this task has been completed {done: 2006-12-16 23:15 PST} Support for other date related events needs to be decided.
Other Attributes
Dependencies | Child TasksDependencies are added by using indentation using a symbol or symbols - usually 4 spaces but this can be set by the user. Parent task dependent task another dependent taskA parent taska sub task dependent on the above taskanother task The rules governing behaviour of child tasks will be outlines in ChildBehaviour. Other IdeasFoldingIf +tag is used at the start of a line - then -tag might be used to indicate folding - or hiding of child tasks during normal display. This could be used to craft the exact display of tasks. +tag this task is open +tag so this is displayed-tag this is closed+tag and this -tag so this would be hidden Multiple LinesUsing multiple lines per task / todo makes parsing the file difficult. However, it should be considered if benefits can be identified. |
► Sign in to add a comment
jhghjigh
Is there any pragmatic reason to keep the project and context syntaxes different? For example:
@weekend @homeimprovement Fix the screen door @weekend @homeimprovement Fix the screen door
It seems like both are useful for grouping, selecting items for a report, etc. Why distinguish?
With the context syntax, you can quickly see all the tasks that you can do by phone while waiting in traffic, for example. I suppose you could just search for a tag "phone" with the same effect. However, I can imagine a case in which an engineer might be designing a phone and have tasks that require phone contact as part of the project. Then "@phone +phone get prices from parts distributor" might make sense. I suppose that's a bit of a stretch, but it does demonstrate the logic of separating distinct ideas to simplify viewing and even parsing the todo.txt file in the shell script.
Re: dependencies, can we have a command similar to the following: $ > todo dependant 3 1 # One is now dependant on 3.
With reverse commands to do the opposite...