Removing a tab does not remove dependency, even if file is saved and reopened -- and indents give wrong picture

[poetaman]

This one is a bit of a nightmare to work with...

Imagine we create a file with four tasks like this:

* [ ] task-a
* [ ] task-b
    * [ ] task-c
    * [ ] task-d

Upon saving, task-c, and task-d will correctly appear as "BLOCKING" task-b. Such dependencies are based on -- and rightly so -- indentation.

Now, lets imagine the user reindents the tasks with the hope to undo dependencies. Lets say the user removes indents and the tasks appear like this:

* [ ] task-a
* [ ] task-b
* [ ] task-c
* [ ] task-d

Even after saving and reopening the file, if one were to hit <CR> on lines of task-b/c/d, it will still show that b is blocked by c & d. The indents too are gone! So task-c and task-d don't appear to have indents, and there is no clean way of visualizing they are blocking task-d. Given the indents don't show that picture, there is something broken.

As a sidenote, if user presses sequence <leader>tD while on line of task-b, task-b is deleted but task-c and task-d maintain their indentations -- thus ready to become dependencies of task-a upon a :w. While this is not a bug per se, and perhaps one can make it into a practice to reindent task-c and task-d after deleting their parent, it would be good to document the sequence of steps one needs to take so they don't get reassigned as children of tasks-a.

[tbabej]

Does this happen also if the tasks are generated by a viewport?

[poetaman]

@tbabej Thanks! It does not happen if tasks are under viewport. I think I am always going to use viewport as I have not come across a reason not to. So my immediate issue is resolved. If you don't see a need for supporting non-viewport case, please feel free to close this issue.

Btw, one more side-note. it would be a good idea to mention somewhere to users to not delete a parent node inside a viewport by using vim's line deletion sequences like dd, etc. Then when the user will save the file with :w<CR> they will hit an unintended problem: multiple parents found. This won't be immediately visible from looking at the viewport, and might turn confuse+demotivate people who are giving taskwiki a try. Perhaps this should be mentioned where the mapping <leader>tD is described.

[tbabej]

If I understand correctly, the scenario you're describing is the following:

## Kitchen reconstruction | pro:kitchen
* [ ] task-a
* [ ] task-b
    * [ ] task-c
    * [ ] task-d

Then you go and if you delete (in the dd sense the second task, you get):

## Kitchen reconstruction | pro:kitchen
* [ ] task-a
    * [ ] task-c
    * [ ] task-d

and save the file with :w or just plain :TaskWikiSaveBuffer.

What happens on save is that the tasks c and d get marked as dependent on a, but their previous dependency on b is not removed. The task b is still, however, pending and matches the viewport, so it will try to be regenerated next time the viewport is refreshed, and now we have the nefarious situation where c and d depend both on a and b.

In your suggested solution this problem is avoided by the fact that hitting <leader>tD in all likelihood removes the parent task from the viewport (this is not guaranteed, but most viewports exclude deleted tasks - this is the default), so the tasks do not end up with multiple parents displayed in this particular viewport.

[poetaman]

@tbabej Yep you got it right. The way I am using viewports so far, I prefer pressing rD after placing cursor on <char> part of [<char>]. It keeps deleted task with [D] in that place till the next write. That way if I have the same task also in another viewport above the last one (where I do all edits), the deletion is still applied. I actually have a ticket for that: https://github.com/tools-life/taskwiki/issues/346. This also works visually, from UI perspective, because the task with [D] gets immediately colored with a different highlight group.