Open tbabej opened 6 years ago
Migrated metadata:
Created: 2014-11-28T19:54:21Z
Modified: 2015-03-01T00:35:29Z
Scott Kostyshak on 2014-11-30T15:52:39Z says:
Thanks for bringing this up. I agree this would be nice. It would also make VT-47 unnecessary (although VT-47 is easier to implement). This would require some thought. For example, what if you are typing an annotation and VIT detects that a change occurred? Should the data be reread? Also note that in some sense this is related to VIT using task IDs and not UUIDs, which can lead to the corruption you talk about. In any case, I won't be able to get to this for a while, although a patch would be welcome.
Nemo Inis on 2014-12-03T20:44:52Z says:
It's not just a VIT problem, I think, more of a consequence of the decision to do away with explicit remote merge commands in taskwarrior. If in a terminal I do a "task next", then "task 43 modify
It's just that VIT has more of a risk exposure, since the time between displaying the task list and the user taking an action may be great if VIT is just sitting there in an open terminal window. Monitoring the data dir and refreshing when a change is detected (or even periodically or strategically, as suggested in VT-47) would reduce that risk exposure to even below that of taskwarrior. Reducing the risk to 0 should be left to the taskwarrior folks, since they're the ones advocating the new sync mechanisms.
Nemo Inis on 2014-11-28T19:54:21Z says:
VIT does not monitor the task data directory ( ~/.task or wherever it is) for changes. Such changes can occur due to remote sync, i.e. a change made on another machine is propagated to the machine where VIT is running, using whatever sync mechanism the user has in place. A simple refresh (ctrl-L) or a change of filter, or most other operations will trigger a re-read of the data, so this is not a major issue. However it can be unnerving to still see in VIT tasks that you know you have modified elsewhere. And if you make changes to such tasks without a refresh first there is a risk of corruption or data loss. VIT should monitor the data directory (using callbacks from File::Monitor for example) and trigger an automatic refresh when anything changes (maybe after a small delay to give the sync mechanism time to finish).