Repository navigation
Conversation
174a055 to
1e3e174
Compare
Add support for TaskChampion's iterative tasks. - Add iter and iter_type as built-in UDAs - Add a read-only iter_count column so it is not treated as an orphan and shows up in info - Reset iter_count on duplicate so the copy starts a new series - Add the ITERATIVE virtual tag, include iterative tasks in PENDING, and add an Iterative row to stats - Add Task::is_open() and Task::is_pending() instead of the various pending/waiting checks so that all the reports just work - Document iter and iter_type in task(1) - Bump the tc_cpp_test to accept the new rusqlite messages This currently uses a TC hash rather than version tag, since there isn't a release with it yet.
1e3e174 to
7227be4
Compare
There was a problem hiding this comment.
Open question for now -- should iterative tasks be labeled as "experimental" at first?
If so, we'd also want to clarify what we mean by that. For example, we might be able to promise that the database will have a migration path forward without promising that the cli will not change.
|
I was curious what would happen if you |
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
At this point this is my last remaining comment though it may have been missed since it wasn't in a review. Feel free to resolve all the review comments -- I believe I can't without repository write access. |
|
Nice catch. I think there are two reasonable options, either it could error, or it could actually make it just a normal pending task. I'm not sure which one is more user friendly. What do you think? |
|
My weakly held opinion is that an error suggesting they clear
|
| if (before.getStatus() == Task::iterative && after.get("iter") != "" && | ||
| Task::textToStatus(after.get("status")) == Task::pending) |
There was a problem hiding this comment.
I think this should be applicable regardless of the status they try to set so maybe the last condition should be after.getStatus() != Task::iterative. That's what the error message implies anyway.
|
|
||
| .RE | ||
| While a task is iterative, iter_type cannot be removed, the last of due, | ||
| scheduled and wait cannot be removed, and its status cannot be set to pending. |
There was a problem hiding this comment.
| scheduled and wait cannot be removed, and its status cannot be set to pending. | |
| scheduled and wait cannot be removed, and its status cannot be modified. |
ryneeverett
left a comment
ryneeverett
left a comment
There was a problem hiding this comment.
In terms of strategy, I'd suggest labeling this feature as experimental wherever is appears in the docs and releasing it. The upside of this approach is that we can make UI or behavior changes in subsequent minor versions without violating stability expectations. The downside is that communicating the meaning of "experimental" is a bit delicate:
- the data is stable -- we're not going to change the format without a migration
- it isn't provisional -- we're not going to delete the feature altogether
- UI and behavior are subject to change -- therefore we're free to adapt to user feedback
Something like:
Experimental: UI and behavior of iterative tasks are subject to change in minor versions based on user feedback. However, the database format is stable and we're confident this will replace the recurrence system in a future release.
|
The pre-commit formatting check failure seems legitimate. |
|
Agreed regarding the "experimental" annotation. |
Add support for TaskChampion's iterative tasks.
This currently uses a TC hash rather than version tag, since there isn't a release with it yet.