Some tasks need to be repeated again and again. Org mode helps to organize such tasks using a so-called repeater in a ‘DEADLINE’, ‘SCHEDULED’, or plain timestamps68. In the following example:
** TODO Pay the rent DEADLINE: <2005-10-01 Sat +1m>
the ‘+1m’ is a repeater; the intended interpretation is that the task has a deadline on ‘<2005-10-01>’ and repeats itself every (one) month starting from that time. You can use yearly, monthly, weekly, daily and hourly repeat cookies by using the ‘y’, ‘m’, ‘w’, ‘d’ and ‘h’ letters. If you need both a repeater and a special warning period in a deadline entry, the repeater should come first and the warning period last
DEADLINE: <2005-10-01 Sat +1m -3d>
Deadlines and scheduled items produce entries in the agenda when they are over-due, so it is important to be able to mark such an entry as done once you have done so. When you mark a ‘DEADLINE’ or a ‘SCHEDULED’ with the TODO keyword ‘DONE’, it no longer produces entries in the agenda. The problem with this is, however, is that then also the next instance of the repeated entry will not be active. Org mode deals with this in the following way: when you try to mark such an entry as done, using C-c C-t, it shifts the base date of the repeating timestamp by the repeater interval, and immediately sets the entry state back to TODO69. In the example above, setting the state to ‘DONE’ would actually switch the date like this:
** TODO Pay the rent DEADLINE: <2005-11-01 Tue +1m>
To mark a task with a repeater as DONE, use C-- 1 C-c C-t,
org-todo with a numeric prefix argument of ‘-1’.
A timestamp70 is added under the deadline, to keep a record that you actually acted on the previous instance of this deadline.
As a consequence of shifting the base date, this entry is no longer visible in the agenda when checking past dates, but all future instances will be visible.
With the ‘+1m’ cookie, the date shift is always exactly one month. So if you have not paid the rent for three months, marking this entry DONE still keeps it as an overdue deadline. Depending on the task, this may not be the best way to handle it. For example, if you forgot to call your father for 3 weeks, it does not make sense to call him 3 times in a single day to make up for it. Finally, there are tasks, like changing batteries, which should always repeat a certain time after the last time you did it. For these tasks, Org mode has special repeaters ‘++’ and ‘.+’. For example:
** TODO Call Father DEADLINE: <2008-02-10 Sun ++1w> Marking this DONE shifts the date by at least one week, but also by as many weeks as it takes to get this date into the future. However, it stays on a Sunday, even if you called and marked it done on Saturday. ** TODO Empty kitchen trash DEADLINE: <2008-02-08 Fri 20:00 ++1d> Marking this DONE shifts the date by at least one day, and also by as many days as it takes to get the timestamp into the future. Since there is a time in the timestamp, the next deadline in the future will be on today's date if you complete the task before 20:00. ** TODO Check the batteries in the smoke detectors DEADLINE: <2005-11-01 Tue .+1m> Marking this DONE shifts the date to one month after today. ** TODO Wash my hands DEADLINE: <2019-04-05 08:00 Fri .+1h> Marking this DONE shifts the date to exactly one hour from now.
You may have both scheduling and deadline information for a specific
task. If the repeater is set for the scheduling information only, you
probably want the repeater to be ignored after the deadline. If so,
set the variable
repeated-after-deadline. However, any scheduling information
without a repeater is no longer relevant once the task is done, and
thus, removed upon repeating the task. If you want both scheduling
and deadline information to repeat after the same interval, set the
same repeater for both timestamps.
An alternative to using a repeater is to create a number of copies of a task subtree, with dates shifted in each copy. The command C-c C-x c was created for this purpose; it is described in Structure Editing.
Org does not repeat inactive timestamps, however. See Timestamps.
In fact, the target
state is taken from, in this sequence, the ‘REPEAT_TO_STATE’ property,
org-todo-repeat-to-state if it is a string, the
previous TODO state if
t, or the first
state of the TODO state sequence.
You can change this using the option
org-log-repeat, or the
‘STARTUP’ options ‘logrepeat’, ‘lognoterepeat’, and ‘nologrepeat’.
With ‘lognoterepeat’, you will also be prompted for a note.