3 ms·
Haven't tried it but for CLI apps, numbered references to items (named ID in taskwarrior) are often troubling for me. In the Quick Demonstration[0] it seems th
by rndstr 10y ago
Haven't tried it but for CLI apps, numbered references to items (named ID in taskwarrior) are often troubling for me.
In the Quick Demonstration[0] it seems that deleting will re-number the items but doing
$ task 1 done
$ task 2 done
and then `task list` should actually lead to
1 Buy eggs
shouldn't it?
or then
3 Bake cake
if IDs are kept
[0]: https://taskwarrior.org/docs/start.html https://taskwarrior.org/docs/start.html
- hjgrtrtr 10y agoIDs are kept in between the runs
- cpro 10y agoI am not 100% sure how Taskwarrior does it, but when I built my own dead simple task manager (for people that want to finish tasks and not organize them), I gave the tasks random unique IDs. https://github.com/prophittcorey/t.rb https://github.com/prophittcorey/t.rb
- lgas 10y agoThis same thing bothered me, so I installed task warrior to try it out. It appears that "task list" actually has a side effect of re-numbering the IDs. So the example is actually correct behavior, but if you issue an extra "task list" command in between "task 1 done" and "task 2 done" then yes, you would the result you expected. This (IMHO) terrible design is what will keep me away from task warrior.
- fvargas 10y agoWhy is this "terrible design"? I'm not a Taskwarrior user, but I did read through their introduction and didn't notice this perhaps odd behavior in the example until reading this comment thread. Looking at it again, I concluded that either the id associations last observed by the user are the ones that get used, or that the example was simply incorrect. As you discovered, the id associations are based on what the user last observed when running task list, which may feel like an unnecessary complexity. But consider the alternative. A user runs task list and wants to mark as done multiple tasks. After marking the first task as done, they would need to start calculating offsets for the next task. After doing that a few times, your task list might suddenly have multiple gaps in it, which would make it unnecessarily difficult to precisely calculate what the current id is for an item that was initially in the middle of your list. Maybe you deleted 4 items before it and 6 items after it. So, 10 deletions in, how many seconds is it going to take for you to figure out precisely what id you need to be deleting next? It makes sense for the id associations to correspond to those last observed. A user is likely to run task list right before deleting anything and then run a series of done commands. Thus, this feature is a far simpler and quite essential solution to the problem I described above. The alternatives would be to keep track of exactly how you're mutating the task list, or run task list between every few deletions to avoid making a mistake. > This (IMHO) terrible design is what will keep me away from task warrior. I could understand not wanting to give it a try due to lack of this feature. But I think your conclusion is greatly misguided.
- lgas 10y agoI did try it -- and thats what led to my decision not to use it. A reasonable solution to the problem (again IMHO) would be to use permanent IDs and never renumber them. I am comfortable marking task 1654 done. Maybe a manual command you run to renumber them if you're tired of them being high.