[TW-1284] Enhanced control over recurrence

[taskwarrior]

Renato Alves on 2014-03-07T17:08:18Z says:

At the moment recurrence is set by using recur:frequency together with due:date. Due to the overload of the due: operator, some unintuitive side-effects may occur. See for instance TW-309.

A reimplementation should allow the following use-cases:

• due and start of recurrence should be decoupled. Possibly use "due:" and "first:". Allows task add recur:weekly due:2days first:nextmonth wait:firstmonday Do laundry - every week on mondays do laundry until wednesday starting next month.
• Properties are evaluated at creation time of each "children" instead of creation time of the parent. (task add recur:weekly wait:2days to wait any recurrent task 2 days after creation`
• Maintain task creation in sync with calendar (related to deferredEval of dates - "every first monday of the month" type math)

Improvements to the way recurrence works by use of a parent task that generates children have also been discussed before in the IRC:

pbeckingham     djp:  Suppose you do this: task add foo recur:R due:D
pbeckingham     djp: We create one task.  status:pending and it owns an attribute which reflect the oldest incomplete task. 
pbeckingham     djp: Initially that equals D.
pbeckingham     djp: There is no hidden template task.
djp     that's good, but I don't yet grok the mechancs.. 
pbeckingham     djp: Any client, can create a new recurring task from that.
pbeckingham     djp: That new task must be related to the first one.
pbeckingham     djp: On merge, two recurring tasks with different UUID and same due and parent are combined.
pbeckingham     djp: The original task is updated and referenced every time.
djp     almost, that the original tasl is "updated"?
pbeckingham     Yes.
pbeckingham     Something, somewhere needs to track the reucring tasks that are pending or complete.
djp     will that still create a series od done, done, done? don't want to lose that history
pbeckingham     Right, if you lose history, they would get recreated.
pbeckingham     So we can eliminate the hidden task.
pbeckingham     But perhaps we can go further...
pbeckingham     By putting recurrence data in a separate file (recur.data?) we can reduce the other data files to simply containing ordinary tasks.
pbeckingham     ie no special cases     
djp     wow
pbeckingham     Then we need to sync the new file contents.
pbeckingham     So those are the two simplest ideas. 
pbeckingham     There is a third:
pbeckingham     You create a template parent task, and no child tasks are generated.  Instead, you synthesize them every time, on data load.
pbeckingham     So they are (I hate to use this term again) virtual tasks.
pbeckingham     Then if you complete or delete them, the template is updated.  The child never existed.
pbeckingham     But if you modify a virtual task, you get COW semantics and it gets upgraded to a real, non-recurring task.
pbeckingham     End.
djp     so the ones you might see in a list are just "representations" (virtual)?
pbeckingham     Yes.
pbeckingham     Until you touch one, then it's real.
djp     I LIKE that one! It might heve uses beyond recurrence.. and the mechanics might not be to distant from "breaks"?
pbeckingham     That's pretty much it.  I have some notes with more details, but that's the essence of it.  Three alternatives: A1 A2 and B.
pbeckingham     Maybe someone has option C

[taskwarrior]

Migrated metadata:

Created: 2014-03-07T17:08:18Z
Modified: 2015-09-02T00:04:57Z

[taskwarrior]

David Patrick on 2014-06-05T20:29:18Z says:

current suggested new attribute name: "over:" to replace "until:" for parent tasks.