Closed thomasjfox closed 4 years ago
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
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.
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:
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) 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)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)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.
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.
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:
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?