org: Repeated tasks
8.3.2 Repeated tasks
--------------------
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 timestamp. 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/w/m/d/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
completed once you have done so. When you mark a DEADLINE or a SCHEDULE
with the TODO keyword DONE, it will no longer produce entries in the
agenda. The problem with this is, however, 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 DONE
(using ‘C-c C-t’), it will shift the base date of the repeating
timestamp by the repeater interval, and immediately set the entry state
back to TODO(1). 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>
A timestamp(2) will be 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 will no longer
be visible in the agenda when checking past dates, but all future
instances will be visible.
With the ‘+1m’ cookie, the date shift will always be exactly one
month. So if you have not paid the rent for three months, marking this
entry DONE will still keep 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 will shift 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 Check the batteries in the smoke detectors
DEADLINE: <2005-11-01 Tue .+1m>
Marking this DONE will shift the date to one month after
today.
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 ‘org-agenda-skip-scheduled-if-deadline-is-shown’ to
‘repeated-after-deadline’. 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.
---------- Footnotes ----------
(1) In fact, the target state is taken from, in this sequence, the
‘REPEAT_TO_STATE’ property or the variable ‘org-todo-repeat-to-state’.
If neither of these is specified, the target state defaults to the first
state of the TODO state sequence.
(2) 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.
Info Catalog
org: Inserting deadline/schedule
org: Deadlines and scheduling