s:resolve_index referenced an undefined `a:file` (a copy-paste leftover
from wiki_root_for, whose parameter is named a:file) inside the
buffer-owning-wiki loop. Any get_wikilocal() call with no explicit index
while a wiki buffer was current — i.e. the ftplugin BufRead path — hit
`E121: undefined variable a:file`. The local is `l:file`, and the
surrounding `!empty(l:file)` guard already covers emptiness, so the
clause was both wrong and redundant; removed it.
Add development/tests/test-vars-vim.{sh,vim} covering the shim:
per-wiki-index resolution, global-default fallback, out-of-range clamp,
the no-index owning-wiki path (direct guard for this E121), and the
single-wiki shorthand. Wired into CI. 14/14 pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`vimwiki#vars#get_wikilocal(key, N)` previously ignored the wiki-index
argument and always read the scalar `g:nuwiki_*` globals (the first
wiki), so third-party plugins (vimwiki-sync, vim-zettel) got the wrong
wiki's path/ext/syntax in a multi-wiki setup.
Now:
- an explicit numeric index selects that wiki from `g:nuwiki_wikis[N]`,
falling back per-key to the scalar globals;
- with no index, the wiki owning the current buffer is resolved (matching
upstream's `g:vimwiki_current_idx` behaviour);
- an out-of-range index clamps to the first wiki.
The single-wiki shorthand path is unchanged. Verified with a headless
Vim test (by-index, global fallback, clamp, no-arg, shorthand) and the
Vim keymap harness (301/18/21, 0 failed).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Resolves the 18 findings from the parallel codebase review, tracked in
development/vimwiki-gap.md.
Correctness / perf:
- Wiki.config -> Arc<WikiConfig> so cloning a Wiki is a refcount bump (R5)
- WorkspaceIndex::remove is no longer O(n^2): a per-source contributions
map limits the scan to buckets the source actually wrote into (R6)
- render_color now expands color_tag_template (__STYLE__/__CONTENT__),
consuming the previously-dead field; ColorNode documented as an
extension point; 3 renderer tests added (R3/R4)
- wiki_root_for returns empty/nil on no-match instead of falling back to
the first wiki (R2); auto_header honours links_space_char (R7)
Cleanup / dedup:
- Remove dead #[allow(dead_code)] stubs + uncalled pub helpers, narrow
imports (R10/R11)
- Dedup span_of_inline x3 -> InlineNode::span() (R12)
- diary_step single read lock; page_captions single pass (R13)
- Lua auto_header loop -> wiki_list(); detect_current_symbol cleanup
(R14/R18)
Client / docs:
- :VimwikiNormalizeLink Vim cmds -> <q-args> (R17); ftplugin header fix
(R16); vars.vim multi-wiki limitation documented (R15)
- Document 19 config options in README.md + doc/nuwiki.txt; fix
list_margin/shiftwidth doc and stale comments (R1/R9)
- R8 investigated, confirmed not a real bug (documented)
Verified: Neovim harness 307, Vim harness 301/18/21, Rust suite 568, all
0 failed; clippy clean; fresh parallel-agent audit found no regressions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Third-party plugins such as vimwiki-sync and vim-zettel call
vimwiki#vars#get_wikilocal() — a function only provided by the original
vimwiki plugin. Without it, the after/ftplugin loaded by vimwiki-sync
errors on every wiki buffer open:
E117: Unknown function: vimwiki#vars#get_wikilocal
E121: Undefined variable: g:zettel_dir
Add autoload/vimwiki/vars.vim with lightweight stubs for the two keys
vimwiki-sync uses ('path', 'is_temporary_wiki'), reading values from
nuwiki's own g:nuwiki_wiki_root / g:nuwiki_file_extension config so
users don't have to duplicate settings. get_global() is stubbed as a
no-op for completeness.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
gffranco