Recurring tasks

[naggie]

Recurring task definitions should be stored separately and not displayed in any regular view. Instances of such tasks should be displayed when appropriate as virtual tasks (created every listing) until they are modified.

This way, most synchronisation issues are avoided; the main one (which taskwarrior suffers from, IIRC) is where tasks are created on different machines for the same instance resulting in duplicate tasks after sync.

Each instance should keep a reference to its parent recurring task.

Proposed syntax: cron, with shortcuts for add command

• recur:@weekly
• recur:"0 1 * * *"
• @monthly

• RECURRING status/type
• scheduler with https://github.com/robfig/cron
• show-recurring
  ...

[sclee15]

Please also consider relative recursive tasks.

[naggie]

Please also consider relative recursive tasks.

What do you mean by that?

[sclee15]

Please also consider relative recursive tasks.

What do you mean by that?

Something like this.
https://github.com/JensErat/task-relative-recur

[copernico]

"Recursive" tasks (better called "relative recurrence" tasks) are scheduled again when they are completed; the due date of the new occurrence can be set relative to the completion time of the previous occurrence.

[copernico]

As for the syntax, I think something less geeky would be useful, as with taskwarrior: daily, weekly, monthy etc...

[naggie]

Agreed, they'll be commonly used too. I think I'll support both, as the cron method allows for a lot of flexibility.

[copernico]

Do you have a draft implementation of this to take a look at? Or can you elaborate on how you think this should be implemented? I think TaskWarrior does it right (from the user perpective; I haven't looked at their code).

[naggie]

There's a branch but at the moment it has no implementation beyond the change to data structures.

I plan on looking into more detain on how taskwarrior does it in terms of UX.

As for the implementation, dstask won't commit the tasks to disk until they change -- generating them on every invocation. That way, I hope to avoid the duplicate recurring task sync issue that taskwarrior can be prone to.

[trws]

It may be worth not digging into how tw does this too far. Their interface for it is ok, but it has several weaknesses in the implementation beyond the duplication issue:

• no recursive tasks as already mentioned
• time drift: recurring tasks have a fixed offset between occurrences that doesn’t account for things like length of month or leap days, this can be really bad, as for example one month is implemented as 30 days(!!)
• no way to tie scheduled or wait to the due date for recurrence, so if wait is set it is just replicated in the recurrence rather than updated to be the same distance from the new date

Some types of dates and recurrences aren’t going to be expressive in corn format unless extensions are used. Second Thursday org the month for example. Not sure that’s necessarily fatal, but it seems worth mentioning as a potential drawback.

[naggie]

Thanks for the discussion @trws -- it's good to know some pain points of taskwarrior recurring tasks as I've only actually used them a few times.

[copernico]

Thinking about a model to represent recurrent or "automatically rescheduled" tasks....

(I am deliberately avoiding the term recursive in this case, since one task occurrence finishes before the next is scheduled, which is very different from recursion).

I guess for both types of tasks one needs a virtual "blueprint task" from which the actual task instances are fleshed-out at specific points in time, either fixed dates (constants) or other events (variables) such as the completion of another task.

Your thoughts?

[trws]

The term omnifocus uses for that is either "repeat from" or "due again", org-mode seems to call it an "after repeater" or some such, not sure where recursive came from 🤷. As to how they're created, it's usually a replication of the one being completed to create it with an offset applied. For tasks with fixed recurrence you really want the "blueprint" of sorts to store the recurrance, and then replications only for exceptions IMO, but with tasks that repeat from completion rather than last instance, it's a self-perpetuating chain, so the most recent version is what I normally want replicated. They're also a bit simpler that way, since if you look into the future you can't see them again, the future occurrances can't exist until the immediately preceding one is completed.

[strogiyotec]

Hey, waiting for this feature as well, really miss it as I came from TW, BTW thanks for this awesome project

[cgardner]

In the meantime, I found that you can add tasks in the notes that have to be marked off before you can mark a task as done.

I'm trying out using that feature to remind myself to create the next instance

[gour]

Hello,

long-time ex-user of Taskwarrior here...tried with Emacs/org-mode, but returning to Vim/some-cli manager, atm using Etm...my main problems with TW were no support for "recursive" tasks which are referenced as "recursive" in TaskLite and it seems that the long-awaited "recurring overhaul" is not going to happen ever.

Another problem was also with "repeating" tasks and associated time-shift since monthly period was based on 30 days.

Emacs (org-mode) and e.g. Etm do handle this date-arithmetic properly - the latter is .e.g using Python's Pendulum library, so wonder if dstask is going to address this problem as well enabling users to have task like "every 3rd Friday in a month" etc.?

While waiting for "recurring tasks" in dstask, I'm also looking at TaskLite and have a feeling that combination of the two would be (almost) perfect. ;)

Keep up the good work!

[naggie]

Emacs (org-mode) and e.g. Etm do handle this date-arithmetic properly - the latter is .e.g using Python's Pendulum library, so wonder if dstask is going to address this problem as well enabling users to have task like "every 3rd Friday in a month" etc.?

The first version will support recurring tasks such that they occur at a set interval regardless of completion -- but don't pile up. See the fairly recently edited description of this issue for an idea.

[gour]

Emacs (org-mode) and e.g. Etm do handle this date-arithmetic properly - the latter is .e.g using Python's Pendulum library, so wonder if dstask is going to address this problem as well enabling users to have task like "every 3rd Friday in a month" etc.?

The first version will support recurring tasks such that they occur at a set interval regardless of completion -- but don't pile up. See the fairly recently edited description of this issue for an idea.

Nice!

Here are some nice points (e.g. date arithmetic etc.) mentioned in regard. 😉

[Dieterbe]

FWIW there's a couple different flavours of "cron syntax" out there. some cron systems also support syntax such as the suggested daily, weekly, monthy, etc.

[naggie]

yes, though the go one i had in mind does.

[gour]

Hello,

do you have any rough estimate when something might happen in regard to 'recurrence'?

Although I'm using org-roam for taking notes, I still prefer tw, but not having proper support for (many) recurring tasks is constantly pushing me towards org-mode, so, for now, dstask is big hope for us to stay along with ci. 😄

[Dieterbe]

Recurring task definitions should be stored separately and not displayed in any regular view. Instances of such tasks should be displayed when appropriate as virtual tasks (created every listing) until they are modified.
This way, most synchronisation issues are avoided; the main one (which taskwarrior suffers from, IIRC) is where tasks are created on different machines for the same instance resulting in duplicate tasks after sync.

The above was written prior to #90 , where we realized that we could conceivably generate task files for every single occurence, as long as we deterministically generate its UUID/filename. that way, tasks generated on multiple systems representing the same instance would have the same ID, and upon syncing, not result in duplicates. They may result in merge conflicts though, if the tasks look different on both sides. But I think this would only happen in the same sort of situations as where they would also happen with the proposed method (e.g. different notes on both sides)

I don't really understand the proposed method though. whenever an instance of a recurring tasks is done, would the user declare it so, and that would then also result in a task file per instance?

I actually like the idea of not generating a separate task file for every single instance, though i'm not sure if this is feasible, and whether the proposed solution does that.

[rotlaus]

I actually like the idea of not generating a separate task file for every single instance, though i'm not sure if this is feasible, and whether the proposed solution does that.

I like the org-mode way of handling recurrance. After marking a task as done, the task is still a TODO, the Deadline is modified to a new date and a timestamped log entry is put under the task. No need of generating a new task.