We already set this via the COVERALLS_SERVICE_NAME environment variable
in the GitHub Actions workflow, as it's really specific to GHA.
And as it turns out, the fix wasn't really necessary anyway as the
Coveralls.io infrastructure was just temporarily down.
Fixes: d98d5b18ac ("ci: Fix coveralls submission")
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.
