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 is simpler and more reliable/predictable:
"git ls-remote 'heads/'" doesn't return anything, while "grep 'heads/'"
returns all branches, so a taskwarrior push causes most docker images
(those that don't have any TASK_VERSION and fallback to the Dockerfile
default) to be rebuilt, not just the one that needs to be.
For the development branches of taskwarrior, caching 2.5.2 or 2.6.0 is
not sufficient since HEAD is still moving.
Build the tag hash based on the HEAD hash of the development branch in
question.
Coveralls doesn't know that tools-life/taskwiki is the same repo as
tbabej/taskwiki so we need to update this. The rest redirects
automatically and is updated just for consistency.
Gitter room is still called tbabej/taskwiki.
landscape.io is probably dead but the badge still works so I'm not
touching that one either.
The more straightforward `containedin=@TaskWikiTaskContains`
unfortunately doesn't work as it actually means
`containedin=VimwikiListTodo,VimwikiTag,VimwikiEmoticons,…` and that
isn't what we want.
5bf0c89ae8 left a misleading comment in
the code:
# If port was detected, break the search
break
Refactor the code to make it clearer what's going on: we're looking for
the first parent header/preset/viewport of this task, and therefore we
always break. By separating the search and processing of the found
header/preset/viewport, we avoid the confusion.
Related: https://github.com/tools-life/taskwiki/pull/288
The previous refactor traded build step caching for smaller image size,
which in turn made fast caching of built images possible, and allowed us
to speed up CI builds. But almost any change in Dockerfile required full
rebuild of everything (vim & taskwarrior), so changes to the Dockerfile
became more painful.
This commit refactors the Dockerfile to use multi-stage builds, which
brings build caching back: vim & taskwarrior are built in separate
stages, which are cached step by step, and then the build artifacts are
copied into the main tests image and runtime dependencies are installed.
There's a catch, of course: --cache-from doesn't work with multi-stage
images unless the experimental BuildKit backend and its inline cache
export are enabled. This requires docker 19.03, which shouldn't be hard
to obtain but isn't installed by default on Travis CI.
* Switch from Fedora to Alpine. This makes it possible to have smaller
docker images (Alpine is smaller by itself; apk add --virtual makes it
feasible to correctly remove build dependencies) which will be useful
for caching the images somewhere instead of building them in CI again
and again. This is expected to cut the CI test time in half.
* Make versions of python, vim and vimwiki configurable via docker build
args to enable testing of additional environments. This makes the
build slower, but we will fix that by caching.
Unfortunate consequence of doing all the installs in one RUN step is
that docker build doesn't cache the intermediate steps and therefore
modifying the Dockerfile and testing those modifications locally is now
slower than it used to be. This can likely be improved by using
multi-stage builds (and using BuildKit and its inline cache export to
not break the caching we're about to add a few commits later).
Primary motivation for this is speed: GitHub Actions doesn't limit the
number of concurrent jobs to 4, and also provides a docker registry
(GitHub Packages) that we can use to cache the image (building the image
takes cca 5 minutes, fetching it would take less than 10 seconds). This
is done in another commit.
The workflow definition is a bit more complicated because coveralls
support for GitHub Actions is less mature than for Travis CI, so we need
to manually tell coveralls that all parallel builds have finished and
that it can publish the combined result.
Commit 9f3a52e73b meant to only disable remembering options, but it
ended up disabling remembering of cursor position as well. The cursor is
still restored by last-position-jump (see usr_05.txt) if one has that in
their vimrc, but whenever there are any folds in the view, restoring
these folds resets the cursor again.
Not disabling saving of cursor position fixes this in the default
configuration and lets the user tweak viewoptions however they like.
Did not actually change the code. Instead changed the docs referring to
the "priority" field incorrectly as "pri", and changed `constants.py` to
reflect the correct name for it.
This makes it easier to understand the interaction between the outer and
inner make, as one doesn't need to dig through docker-compose.yml and
possibly Dockerfile to find what command will be run.
It does break the ability to run `docker-compose run --rm tests` but
that's a good thing I believe: I only ever use that when I need a shell
in the container for debugging purposes.
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
