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.
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.
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.
Tinmarino
Brennen Bearnes
xgpt
dmitry kim
Brennen Bearnes
Felix Wolfsteller
Philipp Oberdiek
Philipp Oberdiek