Problem:
The loading of a .md file was slow due to multiple nested lookback.
It is advised in vim help to prefer \zs, see :h /\@<
Anyway, it is useless to nest them.
089.080 000.085 000.085: sourcing /home/mtourneb/.vim/after/syntax/vimwiki.vim
089.264 005.184: opening buffers
089.322 000.058: BufEnter autocommands
089.323 000.001: editing files in windows
089.414 000.091: VimEnter autocommands
089.415 000.001: before starting main loop
303.698 214.283: first screen update
303.700 000.002: --- VIM STARTED ---
Solution:
Remove the function s:expand_delimiter in vars.vim.
It was doing a duplicate job with vimwiki#u#hi_expand_regex
And ... well avoid lookback as much as possible
091.784 000.087 000.087: sourcing /home/mtourneb/.vim/after/syntax/vimwiki.vim
091.991 006.034: opening buffers
092.050 000.059: BufEnter autocommands
092.052 000.002: editing files in windows
092.172 000.120: VimEnter autocommands
092.173 000.001: before starting main loop
112.574 020.401: first screen update
112.578 000.004: --- VIM STARTED ---
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.
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>
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.
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`.
R. David Dunphy
Tinmarino
Brennen Bearnes
Philipp Oberdiek
Philipp Oberdiek
Steven Stallion
Stefan Schuhbäck
Brennen Bearnes
Amit Beka
Tomas Janousek
mtourneb
Ryan Winograd