Vim preserves folds by writing line jumps into the view script, so it's
better to load this script with the original file contents and only then
refresh from taskwarrior. The folding is still often broken when the
buffer is updated, but that can now be considered a vim bug and may
perhaps one day be fixed (or even worked around, if one is persistent
enough). Loading the view after modifying the buffer is simply wrong,
that can never ever work.
* simplifies code a bit
* avoids triggering autocmds on *.wiki files outside of registered vimwiki
* prevents reordering of autocmds when switching wiki pages
The last bit is my main motivation: I need to add a BufEnter autocmd (to
~/.vim/after, not to taskwiki itself) and I'd love to rely on
`cache.load_current()` having been called already.
This reverts commit b00e886142.
This fixes reporting of coverage by the few tests that run outside of
vim.
The commit that is being reverted doesn't explain why it was committed,
and the git history suggests it was reverted once and then reintroduced
later again. None of those commits explains the why. I can only guess
that the last time this was committed was an attempt to fix coverage
reporting to outside of docker, which it didn't, and additionally it
made coverage gathering less robust (see previous commit). So this is
yet another fix for the inaccurate coverage reporting.
Or maybe it was because `--cov` without `=taskwiki` an argument reports
coverage for tests instead of taskwiki code? Nevermind, I guess, now it
works well.
Not only can we stop ignoring the errors, this also fixes
TestInfoActionNotTriggeredByEnterOnLink which would otherwise cause vim
to complain about g:vimwiki_wikilocal_vars not being available.
`has('python')` and `has('python3')` work the same in Vim and Neovim, so there's
no need for that extra check. That check is even wrong, since Nvim's `:python`
and friends won't work either as long as the Python provider isn't installed as
well.