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.
Adds sentence to allow for keyword searches for "orphaned" to hit on this function to find missing links. "Orphaned" or "Orphan" is used to describe such files in similar PKM software used in the PKM community.
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>
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.
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
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
Enable the user to conveniently set the regular expression used for the
`VimwikiTodo` syntax group, instead of the defaults which might be
more suitable to code.
This setting is now also local per wiki.
Signed-off-by: Amit Beka <--->
Co-authored-by: Amit Beka <--->
Mapping `<Tab>` and `<S-Tab>` at insert mode sometimes collide with
other plugins which utilize these for completions (e.g. coc example
mapping).
Since for many users the case for completion is more frequent than table
editing, this patch enables changing these mappings using the options
`<Plug>VimwikiTableNextCell` and `<Plug>VimwikiTablePrevCell`.
This patch makes it easier of those using multiple plugins and have no
desire or knowledge in debugging the collision.
It complements #1030 by providing a more direct and documented method
for setting custom keymappings.
Signed-off-by: Amit Beka <--->
Co-authored-by: Amit Beka <--->
Neovim has a different method of marking applied patches, using neovim
versions, since patches from Vim are not merged by chronological order.
Signed-off-by: Amit Beka <--->
Co-authored-by: Amit Beka <--->
* Allow VimwikiToggleListItem mapping to be replaced
Currently VimwikiToggleListItem mapping cannot be removed but only new mapping
to it can be added. This commit will allow to add custom binding to this
function and release default mapping of <C-space> and <C-@>, which was how it
was before https://github.com/vimwiki/vimwiki/pull/686
* Update changelog + contributor list
* endi -> endif
Co-authored-by: Tinmarino <tinmarino@gmail.com>
taskwiki integrates vimwiki with taskwarrior, and in doing so changes
the semantics of checkboxes a bit:
* [ ] Install Taskwiki | pending task
* [X] Install Taskwiki | completed task
* [D] Install Taskwiki | deleted task
* [S] Install Taskwiki | started task
* [W] Install Taskwiki | waiting task
It's still desirable for vimwiki to automatically insert `* [ ]` on
`i_<CR>`, `o` and `O` and to syntax highlight all these five as
checkboxes, so I have this in my .vimrc:
let g:vimwiki_listsym_rejected = 'D'
let g:vimwiki_listsyms = ' WSX'
but it results in undesirable behaviour with task hierarchies: when I
add a new subtask (using `i_<CR>`, `o` or `O`)
or mark a subtask done, the parent's checkbox is updated to reflect its
overall completion, to one of ` `, `W`, `S` or `X`, depending on
subtasks completion. This makes little sense in taskwiki. One usually
doesn't want to touch the "parent" task in taskwarrior until the
"subtasks" are done. Setting
let g:vimwiki_listsym_rejected = 'W'
let g:vimwiki_listsyms = ' SX'
results in slightly less illogical behaviour, but it still assumes that
(1) all subtasks are visible (not necessarily true in taskwiki) and
(2) that it's a parent/subtask relationship, not a dependency
relationship (not true in taskwarrior, questionable in taskwiki).
This commit adds an option to disable this behaviour.
Some languages uses comma instead of dot for decimal separator.
When loading vimwiki the following error was occuring
E806: using Float as a String
This is probably a bug in vim, as a workaround when using float can be
str2float.
Similar issue in another project
https://github.com/nathanaelkane/vim-indent-guides/issues/10
According to `:h hasmapto()` if we don't pass the mode as an argument
then only normal, visual and operator-pending modes are checked.
Lets pass the mode explicitly to allow overwriting insert mode mappings.
Doc: Fix: Changed one occurrence of "vimwiki-global-options" back(?) to "vimwiki-syntax-options".
Problem: Duplicate tag
Solution: Delete one
Co-authored-by: Edward Bassett <edward.bassett@ualberta.net>
Refaction:
- Add g:vimwiki_syntax_list to set syntaxlocal variables
- Delete: syntax/vimwiki_markdown.vim and friends
- Change: vimwiki_syntax_variables -> vimwiki_syntaxlocal_vars for consistency
- Include: some doc in design notes