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.
Let coverage.py handle generating the filename and saving data at exit.
This is more robust: it adds a random suffix as well so if one process
creates two Coverage objects, they don't write to the same file like we
did. This is another way to fix the inaccurate coverage reporting.
From my experiments it seems that the first Coverage object started (and
thus the last that saves its data) only covers the loading of modules
(defs, classes, etc.) whereas the second one, whose data is overwritten
by the first, contains the actual coverage generated by running the
tests.
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.
In markdown, there's no ' =' after '|', so the '+' in the filter regex
doesn't match. Let's allow filter to be empty and distinguish between
viewports and presets using negative look-ahead.
This fixes the failing TestViewportsTaskGenerationEmptyFilter test.
This is a preparation for adding additional commands to the test, like
postprocessing the coverage data, which needs to be processed in the
container (unless we somehow copy the data out of it; but then, we
already install coverage and coveralls inside it, so...).
Additionally, this makes it a bit easier to run the tests locally, which
is helpful when investigating errors. Just a tiny bit, though: it still
requires setting up a fake home with a reasonably minimal .vim and a
python environment with vimrunner.
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.
We're mounting taskwiki read-only (because the docker container runs as
root) so place the pytest cache elsewhere. This means re-running failed
test isn't possible now. If that is desired, we may run the container as
current user (may require libnss-unknown) instead, later.
This reverts commit 7b823ace5b.
Python in Travis is only used to merge the coverage results (in fact,
not even that, as those results never get out of the docker image), it
doesn't affect the tests in any way.
After updating python to 3.8 the following error pops up when entering
vimwiki:
```
"~/vimwiki/README.md" 63L, 1510C
Error detected while processing ~/dotfiles/vim/bundle/taskwiki/ftplugin/vimwiki/taskwiki.vim:
line 33:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/main.py", line 640, in <module>
WholeBuffer.update_from_tw()
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/errors.py", line 26, in wrapped_function
original_function(*args, **kwargs)
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/decorators.py", line 9, in wrapped_function
vim.command('let save_pos = getpos(".")')
vim.error: Vim:~/dotfiles/vim/bundle/taskwiki/taskwiki/short.py:41: SyntaxWarning: "is not" with a literal. Did you mean "!="?
```
Changing from `is not` to `!=` solves this issue.
