Tasks being overwritten on save
First, thanks for the great plugin! I am just starting, but I think it will be very useful for me.
I am sure this is a problem with my setup, but I do not know how to debug or see any output from the plugin, so I apologize for making an issue.
I have a non-standard data location for taskwarrior. I set it by setting $TASKDATA to something. I then create a task in my wiki and it shows up in the data correctly. However, when I try to do anything to this task, like start it or complete it, when I save the wiki file, it reverts. I can look in the task (task # info from the cli) and sure enough, as soon as I save it undoes whatever I did. Here are some examples (most of them are 1s apart where I immediately saved. Sometimes I waited 10 seconds):
2021-01-13 18:08:05 Start set to '2021-01-13 18:08:05'.
2021-01-13 18:08:07 Start deleted (duration: PT2S).
2021-01-13 18:08:14 Start set to '2021-01-13 18:08:14'.
2021-01-13 18:08:20 Start deleted (duration: PT6S).
2021-01-13 18:09:28 Due changed from '2021-01-13 00:00:00' to '2021-01-14 00:00:00'.
2021-01-13 18:09:30 Due changed from '2021-01-14 00:00:00' to '2021-01-13 00:00:00'.
2021-01-13 18:10:42 Start set to '2021-01-13 18:10:42'.
2021-01-13 18:10:43 Start deleted (duration: PT1S).
2021-01-13 18:12:09 Start set to '2021-01-13 18:12:09'.
2021-01-13 18:12:11 Start deleted (duration: PT2S).
2021-01-13 18:12:14 Start set to '2021-01-13 18:12:14'.
2021-01-13 18:12:19 Start deleted (duration: PT5S).
2021-01-13 18:12:35 Start set to '2021-01-13 18:12:35'.
2021-01-13 18:12:54 Start deleted (duration: PT19S).
2021-01-13 18:12:57 Start set to '2021-01-13 18:12:57'.
It also reverts when I do :TaskWikiBufferSave.
This behavior occurs independent of whether I set g:taskwiki_data_location or not.
My VIM version is 8.2, I am using taskwiki commit b280e28ac8076a82d084a0b0be96c4edf6592636, and taskwarrior version 2.5.1.
I've seen a similar thing when a task was displayed in multiple viewports, and thus a change in the first viewport would be overwritten by an entry in a viewport below. See https://github.com/tools-life/taskwiki/pull/222
Hmmm yes I could see this. I only have one viewport, and am trying to edit the task outside the viewport. But you are correct, if I do the action in the viewport, then it works. It even updates the task outside the viewport when I do :TaskWikiBufferLoad.
So am I not supposed to have tasks both inside and outside of viewports? My goal was to have a viewport at the top that had all tasks due today or overdue, but then I could set the tasks anywhere else.
After playing around, it looks like viewports also do weird things when trying to delete. If I try to delete the task outside of the viewport, it remains in the viewport. If I try to delete the task in the viewport, it comes back whenever I do :TaskWikiBufferLoad.
I guess I am using Viewports incorrectly?
After some more playing around, the delete one is the worst. If I delete it outside a viewport, it deletes the line from the wiki. However, the viewport reverts it on save, so the task goes back to pending, but it does not return to the line where it was deleted!
As far as I understand and use taskwiki, any task edit outside of any viewport where that task appears needs to be followed by reload.
(I have a hook that reloads the taskwiki page whenever I touch taskwarrior db outside of vim, and I don't use tasks outside of viewport or tasks visible in several viewports at once, so I'm not hitting this issue often.)
Okay, thanks for the advice. I guess I need to change my workflow. But this definitely seems like a bug.
Also, what do you mean by "reload"? When I do a bufferload, it basically does what I say above and pushes the viewport state to taskwarrior. So I cannot see a way of doing anything to a task outside of a viewport and having it stick.
:TaskWikiBufferLoad should be the other way around: push the taskwarrior state to taskwiki.
:TaskWikiBufferLoadshould be the other way around: push the taskwarrior state to taskwiki.
That is what I thought as well, but it appears to do the opposite.