Handling of "mark recurring tasks as done"

[thomasjfox]

Hi Vladimir,

I have some less important recurring tasks, but still with a due date set to nag me to do them once in a while. If a task is due every week and I didn't do it for a while, I need to mark it as done multiple times. Example:

Today 2020-07-22:

$ ttdl d 53
Changed ttdls:
  # D P Created    Finished   Due        Subject
-------------------------------------------------
 53 R   2020-06-22            2020-07-11 Read newspaper article rec:1w
-------------------------------------------------
1 ttdls (of 115 total)

$ ttdl d 53
Changed ttdls:
  # D P Created    Finished   Due        Subject
-------------------------------------------------
 53 R   2020-06-22            2020-07-18 Read newspaper article rec:1w
-------------------------------------------------
1 ttdls (of 115 total)

$ ttdl d 53
Changed ttdls:
  # D P Created    Finished   Due        Subject
-------------------------------------------------
 53 R   2020-06-22            2020-07-25 Read newspaper article rec:1w
-------------------------------------------------

Improvement idea: When marking a recurring task as done, pick the next due date until the new date is later than $now.

What do you think?

[VladimirMarkelov]

I thought about it in the very beginning and decided to keep the way it works now. But I did not think of such frequent recurrences :)

It seems the same is true for threshold. If it exists, done changes it as well. It may be a vary rare case when a person uses threshold and recurrence but it seems OK to change it as well. Maybe count how much due is in the future, and change threshold by the same time

[thomasjfox]

Thanks, new code works like a charm!

I gave the implementation some more thought and have a proposal for a slightly tweaked behavior:

Let's say one has a task like "pump bicycle tires rec:30d" or "charge NiMH batteries rec:60d". When one misses out on those tasks and finally gets them done within a ~10 day delay, it doesn't make sense to pump the tires the next time in 20d.

I think a slightly better behavior would be to use $now + recurrence interval as the new due date.

The only downside I can think of: One forgot to mark a task as done and just notices a week or more later. Then it would move the next recurrence undesireably in the future.

For me personally I'm more likely to miss a "soft" due date by a few days and then finally get the task done. Hard due dates have to go in the calendar.

[VladimirMarkelov]

I think a slightly better behavior would be to use $now + recurrence interval as the new due date

It works great for mentioned cases like "pump bicycle tires rec:30d", but what about a case "pay credit card due:2020-07-15 rec:1m"? I pay the card usually at a random day between 4-10 days before the deadline. With the tweaked rule its due date will move from "correct" one that is undesired in this case. The same for birthdays that I have in the list, too.

I see a few ways(maybe there are more) to solve this:

1. Extra command-line option to move rec days after today, not after the current due (con: harder to use due to new argument; pro: done and rec still works for any case)
2. Do not use rec and just do ttdl edit --set-due 60d to manually set a new date in 60 days from now (con: done is unusable here and one has to remember how to process a given todo; pro: it is already implemented and no changes to TTDL required)
3. Extra tag in addition to rec + due: when TTDL detects the tag it calculates the new due date using tweaked algorithm (con: writing extra tag that is hard to spot when reading ttdl list output, though it may be tiny issue; pro: as in 1 - old todos work as before)

[thomasjfox]

Good points, I actually like suggestion 3, it's the most flexible and automatable. It could look like this:

2020-07-25 pay credit card due:2020-09-14 next-due:exact rec:30d
2020-07-25 pump bicycle tires due:2020-09-09 next-due:from-done rec:30d

if next-due is not given, it defaults to exact, meaning the current implementation.

How would the system behave if a recurring task in mode from-done is completed a few days earlier? Should it compute the next due date also earlier? For bicycle tires or other maintenance work it makes sense, not sure if there are cases where this is undesired.

Before we dive into an implementation though I would suggest to first use what ttdl currently has implemented for a few weeks and then see if it's really a problem. One can always use suggestion 2 to workaround this for now.

[VladimirMarkelov]

I agree, the third bullet is the most ergonomic one as it does not require to do anything extra every time. Just set it up once and then execute done as for a regular todo.