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
If a diary page is opened from outside a wiki buffer the diary frequency
and start of week options are not respected as the wiki number is not
yet set for the local buffer.
Fix this by defaulting the wiki number to 0, which is what is done in
vimwiki#diary#make_note() for the diary_rel_path option that suffers
from the same problem.
Example on how to trigger the problem:
let g:vimwiki_list = [{'path': '~/.vimwiki', 'diary_frequency': 'weekly', 'diary_start_week_day': 'monday'}]
$ vim -c VimwikiMakeDiaryNote
Fixes: a3be479d5a ("Add a diary frequency option (#884)")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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 <--->
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.
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.
Track how many leading spaces a list item has in order to determine whether we should start a blockquote.
Note the extra close tag in the added test: this is a pre-existing issue
already present on `dev`.
Jean-Luc Bastarache
Tinmarino
Tobias Mersmann
ysftaha
Thomas Leyh
Tulio Brunoro
Tomas Janousek
Lily Foster
paperbenni
Stephan T
Hugo Hörnquist
Vinny Furia
Reiner Herrmann
Stefan Schuhbäck
Brennen Bearnes
Levi Rizki Saputra
Rane Brown
Niklas Söderlund
yhu266
yuuy
Amit Beka
David Sierra DiazGranados
mtourneb
Benney Au
Ryan Winograd