Dependency indicator not shown anymore when a task has a dependency on a non-pending task

[fdela]

Describe the bug
Dependency indicator is no longer shown for non-pending tasks.
This is a regression introduced by ec1e89d to fix #256

To Reproduce
Display reports showing depends.indicator column, i.e. active, all, list, ls, newest, oldest, ready, recurring and waiting in the default config, and compare to associated task report output.

Expected behavior
Dependency indicator should be shown when a task has a dependency on a non-pending task

Test case
generate-non-pending-deps-indicator.sh.txt

[thehunmonkgroup]

Cannot reproduce. See attached screenshots.

[fdela]

For the newest report, parent commit (4c1190c) showed the following:

Task 2 depend indicator is shown is your screenshot, but its dependency task 1 is pending, and this issue is about dependency on non-pending tasks, so indicators surrounded by red rectangles in my screenshot is what has disappeared with ec1e89d.

Maybe the issue title wasn't clear/precise enough, I'll update it from "Dependency indicator not shown anymore for non-pending tasks" to "Dependency indicator not shown anymore when a task has a dependency on a non-pending task"

task newest shows:

[thehunmonkgroup]

What you're showing seems like a bug in TaskWarrior. Why would you list dependencies for tasks that are non-pending? They've already been handled, IMO that's actually more confusing.

[fdela]

In this case, you don't really list dependencies, but rather state the fact that is has (or had if only non-pending depencencies) a dependency (hence depends.indicator).

Note it is also present in task export so the dependency is not really removed, but merely hidden in reports like e.g. next showing the list of dependencies for a task (depends column).

While I agree that the added value of knowing that a task has a dependency even if only on one or more non-pending tasks is debatable (might be used in some scripts I guess), as a front-end / user interface to TaskWarrior, VIT should be presenting the same information, for compatibility IMHO.

[thehunmonkgroup]

as a front-end / user interface to TaskWarrior, VIT should be presenting the same information, for compatibility IMHO

This is definitely debatable. VIT is not TaskWarrior, and it is specifically not when it's related to how data is displayed.

Take the coloring for example. I took a completely different approach, because all things considered, it seemed superior. I personally think VIT can diverge from TaskWarrior in places where it leads to a better user experience.

This particular difference I'm not sure about, but I can tell you after spending too many hours chasing the goal of 'just like TaskWarrior', I gave that up for a more practical approach, one free to branch out in ways that makes sense.

[fdela]

Sure, by "presenting the same information", I meant the same info ("model") is displayed, not that it should presented the same way ("view"), where e.g. difference of coloring, addition of (BG) helper info, clearer duration formatting (e.g. "yearly" instead of "P365D"), etc. can lead to a better interface without diverging from the underlying "model".

[thehunmonkgroup]

I'm still not sure I agree with your argument. In TaskWarrior, the dependency is preserved in the data, and VIT doesn't do anything to change that.

depends.indicator is a report option, which dictates how the data is displayed. In fact, even in the VIT codebase, depends.indicator is implemented as a formatter. Formatters can be fully customized for different display as detailed here: https://github.com/vit-project/vit/blob/2.x/CUSTOMIZE.md#formatters

This particular case seems like a grey area, and I'm still pondering on which side it falls.

[scottkosty]

I'm not sure what the behavior should be. It might help to make progress if we had a use case for wanting to see dependencies on non-pending tasks. Why would that information be useful? This includes the case that a task is waiting, right? It is hard for me to think about a use case displaying a dependency on a completed task, but I think it makes more sense to think about dependencies on waiting tasks. I suppose that "waiting" means that a task cannot currently be completed, for whatever reason. Thus, in some sense a task that depends on a waited task is blocked.