Tasks should be able to have multiple parent tasks.

[harleypig]

CodeA must be done before DocB and TestC.

FixupD can't be done until DocB and TestC are done. Then there are tasks that are waiting for FixupD to be done.

So the output should look something like

CodeA
  DocB
    FixupD
      Tasks under FixupD
      More tasks under FixupD
  TestC
    FixupD {...}

[linuxcaffe]

Dependency hierarchy with indentation is a killer feature.. and it needs work :) I tried some basic task dependency restructuring, and gave up after the parent tasks refused to give up their children.

[alexandrebarsacq]

So is this limitation a "design choice" as you state in #171 ? Or is there any chance to see this change in the future ?

[morganmay]

Is there any plan to fix this? I use task dependencies extensively, and this bug makes TaskWiki effectively unusable for me. I wish I could get it working, because I already use both VimWiki and TaskWarrior, and it would be handy to be able to integrate them.

[poetaman]

@tbabej @liskin @linuxcaffe Given this issue has been open since 2015, I would assume it's difficult to implement. Before/if/till you consider allowing multiple parents, I propose a simpler workaround that shouldn't be difficult, and at least make taskwiki usable for cases where multiple parents cannot be avoided (world of bug tracking).

Simpler proposal As far as I can tell, taskwiki processes tasks from top to bottom of the file/viewport, one task at a time. Let's say a task is a dependency of two or more tasks in a viewport. Maintain a hash of UUIDs. When a UUID is present in a hash, it means that corresponding task has already been added to the viewport. If it is not present, then it has not yet been added to the viewport. While considering a potential task to be added to the viewport, if it is not present in the hash, then added it to the viewport the way it is done today. Also, add it to the hash. If a task is present in the hash, don't add it as usual to the viewport. Instead add it's contents as a special comment that reads something like this: %%alias <task_description> #<uuid>. All children tasks of such a task will also automatically get commented as they too would have appeared before in the viewport. Though this would be optional. Perhaps conceal the %%alias part, and assign a special highlight group for aliases tasks. Delete any existing %%alias in viewport while expanding the viewport.

This will ensure that a task can be updated only from one place, thus not requiring any additional complexity in taskwiki's codebase, and things will just work. It will at least open up the possibility of using taskwiki for real-world use. Then at a later point if you do intend to open the codebase for a full blown implementation which allows a task to exist in multiple places in a viewport, that would be just an icing on the cake.

Note: I edited the proposal which initially said that taskwiki should note the line number of the task in hash (to provide hyperlink to jump from the aliases to the task). I realized that it will become a buggy feature to have, because line numbers are not relevant after the user starts editing the file... There are neovim extmarks, or vim's text properties that can do that, though it might not be worth the complexity.