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...
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.
Since c8c3cc9a00, vimwiki filetype is set
automatically by :edit, and `set filetype=vimwiki` loads everything
again.
One consequence of loading taskwiki twice is that
taskwiki/testcoverage.py is sourced twice, the Coverage object is
initialized, started, stopped and saved twice (with the same data
filename!) and the coverage report is inaccurate as two trackers write
into the same file.
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.
Without this, TestInfoActionNotTriggeredByEnterOnLink would pass because
it asserts that the buffer is empty, which is what read_buffer returned
if vim was stuck showing an error message. With `PYTEST_FLAGS=-s`, it
would additionally log
E449: Invalid expression received: Send expression failed.
but that's easy to miss.
`TestSuppressedMapping` leaves vim in visual mode and
`vimrunner.Client.quit()` fails with "E481: No range allowed" resulting
in
Vim: Caught deadly signal TERM
Vim: Finished.
This is probably harmless as the `quit()` is followed by `pkill`, but
let's do it the right way anyway.
Since 8d8fd2c20b, the first `setup`
invocation sets g:taskwiki_markup_syntax="None" which is then detected
in `check_sanity` and vim is restarted, this time with correct
g:taskwiki_markup_syntax. This is wasteful and weird, but makes a bit of
sense as a hack to make `MultiSyntaxIntegrationTest` work as the
test_syntax fixture is not available in `setup`.
To fix this:
* make `teardown` idempotent
* let `check_sanity` fail early if the client is not set up yet
* disable `setup` in `MultiSyntaxIntegrationTest`
* let the sanity check and restart logic handle the setup in
`MultiSyntaxIntegrationTest` once `markup` is available
vimrunner.Server.remote_expr waits for the result so we don't need to
sleep, except perhaps if vim does something asynchronously?
Anyway, this doesn't seem to break any tests here, and is noticeably
faster.
vimrunner.Client.command doesn't do any escaping so we can only use
double quotes. Otherwise it does this:
self.server.remote_expr(["VimrunnerPyEvaluateCommandOutput('let g:vimwiki_list = [{'syntax': 'mediawiki', 'ext': '.txt','path': '/tmp/tmpl1hh2nnf'}]')"])
E449: Invalid expression received: Send expression failed.
Vimrunner-python allows to set a custom server name, which is used with
the `--servername` parameter for `gvim`. This way we can restrict the
killing of gvim instances to those, that we have used. For that purpose
we use the standard linux `pkill` utility instead of `killall`.
