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.
`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.
