I was lost because TaskWiki would not work with my nvim. It turned out that my python3 provider was not available. Installing this dependency - pynvim, solved the issue. I hope I can save other nvm users time by providing this info.
`g:taskwiki_disable_concealcursor` is used to control whether or not
Taskwiki sets `concealcursor`. Move the setting of `conceallevel` to
also dpend upon `g:taskwiki_disable_concealcursor`, the reasoning
being that if the user does not want Taskwiki to set `concealcursor`,
they most likely don't want `conceallevel` changed either.
Fixes#325.
There's no 2.5.x branch any more. Change the default to master, i.e. the
latest release, now that the branch actually reflects the release and
no longer includes patches accidentally merged to the wrong branch.
Keep v2.5.1 around just for safety as it probably is the most widely
used release around.
Would be nice if the 2.6.0 branch was named dev or devel and wasn't
about to disappear as soon as 2.6.0 is released... :-/
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.)
Avoids useless reloading of the function. In practice, probably
harmless, but it doesn't belong there, and neither does setting
foldmethod/foldtext, and that is actually harmful (see further commits).
Python 3.5 is EOL since Sep 2020.
Python 3.9 is out since Oct 2020.
taskwarrior 2.5.2 is out since Dec 2020 (released only on GitHub though).
It's a bit stupid to have to update it manually, but until we figure it
out something better...
When a (task)wiki file is opened, viewports are refreshed but the buffer
is not marked as modified and therefore a subsequent :xa doesn't update
the file. This is, IMO, undesired.
vim documentation for the 'modified' option:
This option is not set when a change is made to the buffer as the
result of a BufNewFile, BufRead/BufReadPost, BufWritePost,
FileAppendPost or VimLeave autocommand event. See |gzip-example| for
an explanation.
We don't need the help message as g:tagbar_type_vimwiki is set by
taskwiki itself, and as we're going to refactor this, maintaining the
help is extra work that makes little sense here.
The import isn't needed in python3.
The implementation that was here had several limitations:
* headers containing `[[vimwiki|links]]` are incorrectly marked as
viewports
* headers/viewports nested below such headers aren't correctly nested in
tagbar as they use `header:` to refer to their parent scope
* presets are marked as viewports, and viewports nested under presets
don't correctly nest for the same reason as above
* the logic for marking headers/viewports as `i:inside` is incorrect,
and the motivation for it is unclear
Let's revert to
6c419fba6f/vwtags.py
and then we'll add tests and implement support for viewports and presets
in a way that actually works.
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.
