Up until now, g:taskwiki_suppress_mappings could be used to supress the
leader keys, but it did nothing to the <cr> mapping
(task_info_or_vimwiki_follow_link())
As mentioned in an earlier commit, viewoptions is global, so it's
probably best to override it only temporarily for mkview.
(loadview is moved to autoload just for symmetry and in case we need to
do something more complex, like saving/restoring foldmethod, later)
Vimwiki now resets fold{method,text} on BufWinEnter:
8d4cb7f11d/plugin/vimwiki.vim (L177)8d4cb7f11d/plugin/vimwiki.vim (L325)
so we should do that as well otherwise we get overridden.
If the user actually configured vimwiki to use its folding, by setting
g:vimwiki_folding to something else than '' or 'custom', we should not
replace that. It would be nice if we could somehow augment
VimwikiFoldText and leave the rest intact, but we can't, so it's best to
keep off. Using foldmethod=syntax gets extremely laggy with just a few
hundreds of lines, so we must not force it.
Also, we now need to increase foldlevel in tests because the folding is
no longer being overridden in the default vimwiki configuration, so we'd
get closed folds in tests...
Doesn't belong in syntax, and shouldn't be set unless we need it for
mkview, so move it next to that mkview.
(BTW, it's a bit confusing that we use setlocal for a global option. Are
we hoping it's going to be made local one day? If not, we may as well
change it to `set` to avoid confusion.)
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.
