Setting a global for g:vimwiki_version doesn't seem too egregious, and
lets us reference it cleanly elsewhere.
Removes version header from vimwiki.txt and hardcoding in tagfile
generation.
There's still one instance of that left in test/tag.vader that we should
clean up eventually.
This:
- Changes version number everywhere I could find it.
- Reworks get_version() to dispense with stable / dev division.
- Rewrites CONTRIBUTING.md to describe a new release workflow.
The development/release workflow stuff could use some thought. It's
clunky at best. There's sort of an inherent tension between semver-style
version numbers and the rolling release thing - maybe we should just use
commit hash or something date-based?
Still, it's a start.
It turns out that the target extension here in `ext` has a dot prepended.
Under manual testing, this seems to fix the issue where a wiki with
`markdown_link_ext` set and using `.md` (for example) in links will wind up
taking people to pages with a repeated extension, like `foo.md.md`.
I feel like the repeated use of:
vimwiki#vars#get_wikilocal('ext', link_infos.index)
here should probably be replaced with a named variable like `target_ext`,
but I wanted to touch the minimum lines of code possible for this fix.
If a link contains `.`, then this:
fnamemodify(link_text, ':e')
will return the last .-separated part of the name as extension, and nothing
else will get appended. Instead, we check if the extension is empty _or_
doesn't match the extension for the target wiki, in which case we append
the correct one.
This seems like it works, and might not break anything else, given the
branch of the function that it's in.
Co-authored-by: Brennen Bearnes <code@p1k3.com>
I find this is one of the more common reasons I wind up with way too many
copies of the same file open.
This adds 2 new magic numbers to vimwiki#diary#make_note()'s second
parameter: 4 for `tab drop` and 5 for `drop`. It also checks to make sure
:drop exists in the current build.
Replaces :e in `vimwiki#base#follow_link()` with :drop, making this the
default behavior for pressing <CR> on a link. Checks for the existence
of :drop first, since this isn't available in some builds.
Adds a new :VimwikiTabDropLink and makes this a default for the keybindings
formerly occupied by :VimwikiTabnewLink; leaving :VimwikiTabnewLink
available for backwards compatibility and anyone who still wants the old
behavior.
Doesn't touch the split window reuse functionality, or the
:VimwikiGoBackLink behavior, although I can see an argument for adding
:drop to the latter.
I've wanted this for a while and happened to notice @davidlmontgomery's
patch from 2016 in #238. Code has moved around a little since, but I
think this is correct.
Before updating a listing, check if the update differs from the existing state.
Only then update the buffer, otherwise return early.
Initial reasoning: If `let g:vimwiki_auto_toc = 1` is set, saving a buffer would always update
the `contents`-section, even if there were no updates in this section. This lead to undesired
undo-behavior.
NOTE: this fix was only tested for the toc-listing.
When using vim's native mechanism for `packages`, wildcards (*) are used
in the `runtimepath` since package folders can have arbitrary names.
They were not expanded, thus a path to e.g. `default.tpl` could not be
resolved when calling Vimwiki2HTML.
Resolvesvimwiki/vimwiki#1193
There is an extra space when calling the `basename` command, which causes the following error:
```
Vimwiki: 'basename: extra operand ‘md’
Try ''basename --help'' for more information.
```
Previously TOC links contained a closing </a>-tag, but lacked the
accompanying start tag, leading to invalid HTML. This fixes that, along
with placing class="justcenter" on the correct tag once again.
Hopefully this solves #1084, "Page links with leading slash lead to a
file in working directory, not a page at the root of the wiki", introduced
in 850aace.
It also adds a set of tests for different kinds of wiki links:
- api_base_resolve_link.vader
- link_syntax_markdown.vader
- link_syntax_vimwiki.vader
Includes some fixes for locally-failing tests, removes a test from
test/map.vader and comments out test/config_vars.vader entirely for the
moment.
Code by : Brennen Bearnes <code@p1k3.com>
Problem: I noticed that running :Vimwiki2HTML for a file with a `"` in
the `%title` line would error out. For example, a title like:
%title this will die: "
Causes:
Error detected while processing function vimwiki#html#Wiki2HTML[1]..<SNR>177_convert_file[15]..<SNR>177_convert_file_to_lines
_template:
line 8:
E116: Invalid arguments for function substitute(v:val, "%title%", "this will die: "", "g")
Solution: It seems like the string concatenation here was unnecessary.
At least on my vim 8.1, the evaluated code seems to have access to the
correct variables.
I'm sure there are bigger problems with the HTML generation here, but this
allows my ~2000 pages with titles to render without throwing errors.
Also adds a brief test and removes some unnecessary DeleteFile() calls
from html_convert_default.vader.
Co-authored-by: Brennen Bearnes <code@p1k3.com>
On Windows.
Commits squashed from first to be committed to most recent:
* fix subdir not correct when path using `\`
* fix slice by variable value not supported in vim 7.3
* remove last '\' from path in CustomWiki2HTML
* fix CSS path in CustomWiki2HTML wrong
* remove unused confirm CustomWiki2HTML
* use ==# rather than == in shellescape html.vim
* remove "FIXME this can terminate in the middle of a path component! from
base#subdir
* update doc/vimwiki.txt
* update contributor to doc/vimwiki.txt
* add comment in html#shellescape