-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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
When I marked this task completed today, I get a threshold date 6 months from the previous I'm not aware of how 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." |
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. |
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. |
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! |
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 thet:
deferral date anddue:
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
.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.
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.
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:
again:
adjustment has no+
and thus is computed from today,Further reasoning for the above:
+
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.again:
adjustment to apply to the due date directly. The current behavior is what the user expects.Thanks for reading this far. Any thoughts?
The text was updated successfully, but these errors were encountered: