Rob's implementation of todo.txt is reflective of how I specifically use the todo.txt format. As such, there are a few implementation quirks and special tags that are available to use.
This guide is not a primer on the todo.txt format itself.
Gemini as a protocol does not support forms, so when editing a task, the service cannot pre-fill the text field with the text already in the task. As such, the user must enter a complete task line in the box. I do this by copying the existing task, pasting it into the text field, and making changes in the field before submitting.
I tend to use projects and contexts rather loosely, almost as two classes of tags rather than specific subtask or location markers. As a result, my tasks often have more than one project and context assigned to each one. This service supports multiple projects and contexts associated with a single task.
Subtasks can be created in the canonical form using projects. However, I have some projects that involve more than one level of subtask. To satisfy this need, I use two tags to create an expanded subtask functionality, and these tags are understood by todo.txt over Gemini. The two tags are:
The shortname: tag specifies a one-word name with which a task can be referenced by another task. A subtask then uses the parent: tag to specify the short name of its parent task. A subtask can also specify a short name of its own that its subtasks can reference. For example, if task 1 has the "shortname:example" tag and task 2 has the "parent:example" tag, the service treats task 2 as a subtask of task 1. When looking at an individual task, this service will parse the task's short name (if it has one) and list any tasks that specify the short name as their parent.
Each task can have only one short name; if multiple are specified, the last one will be used. Tasks can have multiple parents. More than one task can have the same short name, in which case a subtask will list all tasks with that short name as parents.
Most of my tasks are actually reminders to do repeating tasks, and thus need some recurrence rules. These rules allow the service to update a recurring task with a new due date, instead of marking the task as finished. They are defined using the following tags:
The recur: tag takes a value in the form of a positive integer, followed by one of four letters: d, w, m or y. The letter indicates an interval of time: days, weeks, months or years, while the number indicates how many intervals will pass before the task is due again. For example, the tag "recur:2w" means the service will update the task's due date to two weeks from now.
By default, the service will calculate the next due date based on the completion date of the task. The user can change this by placing a tilde (~) in front of the value, which will tell the service to calculate the next due date based on the previous due date. For example, if a task was due three weeks ago and has the tag "recur:~2w", then the service will update the task's due date to one week ago.
Only the first recur: tag is used by the service. A malformed recur: tag is treated as a generic tag, and the service will not consider the associated task to be a repeating task, even if other recurrence tags are specified.
The recday: tag is used to fine-tune the recurrence dates of tasks that repeat weekly, monthly or yearly.
When the recurrence interval is set in weeks, the recday: tag takes one of seven single-letter values representing the day of the week:
For example, the tags "recur:1w recday:r" mean the service will update the task's due date to the first Thursday after the completion date.
When the recurrence interval is set in months, the recday: tag takes one of two value types:
When the recurrence interval is set to years, the recday: tag takes one of three value types:
The 12 month abbreviations are:
Multiple recday: tags can be used in a single task. For example, the tags "recur:~1m recday:2m recday:4m" mean the service will update the task's due date to the second Monday or fourth Monday of the month after the previous due date, whichever date is earlier.
A malformed recday: tag is treated as a generic tag, and the service will revert to default recurrence rules for the associated task.
The archive: tag is used to control records of recurring tasks. The only value it takes is "yes".
Setting the "archive:yes" tag means that when a task is marked as finished, the service will update the due date on the original task, and it will make a copy of the original task (with the original due date) that is marked as finished. This allows the user to maintain a record of when previous occurrences of the task were finished.
A malformed archive: tag is treated as a generic tag, and the service will not archive finished occurrences of the task.
=> Return to todo.txt Index | Home
[Last updated: 2022-12-05]
text/geminiThis content has been proxied by September (ba2dc).