Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increment due date according to offset from deferral date (for adjustments from today) #28

Open
owenh000 opened this issue Sep 13, 2021 · 4 comments

Comments

@owenh000
Copy link
Contributor

The suggestion

I would like to suggest a change in behavior when the again action adds a new task. The new task's due: date should be calculated based on the offset between the t: deferral date and due: date of the original task. With the current behavior, a new task is sometimes created with identical deferral and due dates (even when the original task's deferral and due dates were not identical).

Example 1: current behavior, works

This scenario works well with the current behavior. I want to pay the bills on the 14th of each month and complete the task within one week. Because this task is tied to the calendar, the deferral and due dates are both incremented from the original values with again:+1m.

$ todo add "(A) Pay bills t:2021-09-14 due:2021-09-21 again:+1m"
TODO: 1 added.
$ todo again 1
1 (A) Pay bills t:2021-10-14 due:2021-10-21 again:+1m

Both dates are incremented and the offset between the dates is retained in the new task.

Example 2: current behavior, does not work

This scenario does not work with the current behavior. I want to service the car every six months and complete it within one month. This time the new task dates should be based on the completion date instead.

$ todo add "(A) Service car t:2021-09-10 due:2021-10-10 again:6m"
TODO: 1 added
$ date -I
2021-09-13
$ todo again 1
1 (A) Service car t:2022-03-13 due:2022-03-13 again:6m

In this case, the dates are incremented, but the offset between the deferral date and the due date is lost. The due: value is garbage now.

Example 3: suggested behavior

This is the same as example 2 but shows the suggested behavior instead.

$ todo add "(A) Service car t:2021-09-10 due:2021-10-10 again:6m"
TODO: 1 added
$ date -I
2021-09-13
$ todo again 1
1 (A) Service car t:2022-03-13 due:2022-04-13 again:6m

Here, the due date is 1 month after the deferral date just like in the original task.

More discussion

This change is relevant in the following scenario only:

  1. the again: adjustment has no + and thus is computed from today,
  2. a deferral date has been specified, and
  3. a due date has been specified.

Further reasoning for the above:

  1. If a + is used, the user has specified an explicit offset to use for new deferral and due dates. The current behavior, shown in example 1 above, is what the user expects.
  2. If no deferral date is specified, then the user intends for the again: adjustment to apply to the due date directly. The current behavior is what the user expects.
  3. This suggestion is not relevant to a case where no due date is specified.

Thanks for reading this far. Any thoughts?

@munkee
Copy link
Contributor

munkee commented Sep 13, 2021

I agree that it's not ideal what it currently does. I'm no longer using todo.txt very much so I'm unlikely to invest any time in changing it. I see that you're also a previous contributor, perhaps you can fix it yourself and @nthorne will accept your patch?

I will mention that the SwiftDo IOS app which is the other way I interact with my todo.txt also has some weirdness. You can see that I made the task as a clone of yours. Threshold and due date 1 month apart and we are currently between the 2 of them. They use rec: as their recurrence tag and I do as well using export TODO_AGAIN_TAG=rec in my .todo/config.

x 2021-09-13 2021-09-13 pri:C service car t:2021-09-10 due:2021-10-10 rec:6m
(C) 2021-09-13 service car t:2022-03-10 due:2022-03-13 rec:6m

When I marked this task completed today, I get a threshold date 6 months from the previous t: value and a due date 6 months from TODAY. So now the threshold-due interval has shrunk to 3 days. Surely not what is desired there either.

I'm not aware of how topydo handles this situation, but we should probably aim for something approaching consistency between these 3 or more implementations.

I will mention that at least this addon is quite explicit in the README.MD of what will happen though I do agree that it's probably not what anyone would prefer.

"Mark item N as done, and then recreate it with the creation date set as today's date, and any existing due date and deferral date set to ADJUST from today."

@nthorne
Copy link
Owner

nthorne commented Sep 13, 2021

Hi,

Thanks for taking the time to making this well-presented suggestion. Your proposal looks sound to me, but I have also migrated away from the todo.txt system, so it is quite unlikely that I will invest any significant amount of time in the system. I'd be happy to help out with reviews etc, though.

@owenh000
Copy link
Contributor Author

After looking at the again code, I decided to implement this in Python as dorecur, a replacement for the built-in do action. (I do not mean that there is anything wrong with the code here, rather that Bash programming beyond simple shell scripts is to me an exercise in frustration.)

The new add-on can be found at https://github.com/owenh000/todo.txt-cli-dorecur.

Thanks @munkee and @nthorne for the feedback, and thanks for the again add-on which I have used for a long time.

Feel free to close this issue if that seems appropriate. Meanwhile I will be opening a pull request or two for some minor changes to again that I made locally a few days ago.

@nthorne
Copy link
Owner

nthorne commented Sep 16, 2021

I completely understand you @owenh000 , side projects should not be a point of frustration (that's what day jobs are for :) ). I'll keep this one open since I like the suggestion, and me or someone else might find the time to implement this some day. Thanks again for the input!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants