The g:vimwiki_* drop-in was Vim-only: the Lua client read only setup()
opts and g:nuwiki_wikis, so swapping the vimwiki plugin for nuwiki under
lazy.nvim left the existing vim.g.vimwiki_list ignored and nuwiki pointed
at the default ~/vimwiki.
Mirror autoload/nuwiki/config.vim on the Lua side: config.lua now owns a
single resolver (M.wikis / M.scalar_globals) that resolves setup() wikis →
g:nuwiki_wikis → g:vimwiki_list (translating path->root, path_html->html_path,
template_*, ext->file_extension, …) and folds the global scalar defaults
(g:vimwiki_* then g:nuwiki_* then explicit setup() values; built-in defaults
excluded). lsp.lua (payload) and wiki_cfg/wiki_list (buffer commands) both
route through it, so the server and <Leader>ww agree on the wikis.
Extends test-global-shorthand (15 checks) with the vimwiki_list drop-in +
buffer-command resolution + native-wins cases. Config-parity goldens and
keymap harnesses green on both clients. README + known-issues updated
(drop-in is now Vim & Neovim).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two related config-ergonomics features for vimwiki migrants, sharing the
same scalar-global machinery.
1. Upstream g:vimwiki_* drop-in (Vim client). When nuwiki isn't configured
natively, the Vim client reads g:vimwiki_list + g:vimwiki_* globals and
translates them into nuwiki's schema: per-wiki path->root,
path_html->html_path, template_*, css_name, auto_export/auto_toc,
syntax, ext->file_extension, index, diary_*, name. g:nuwiki_* always
wins. Lets a vimwiki user drop in nuwiki without rewriting config.
2. Global per-wiki defaults (both clients). A display/generation setting
given once at the top level — g:nuwiki_<key> / setup({<key>=…}) /
g:vimwiki_<key> — is folded into every wiki as a default; a per-wiki
value overrides it (vimwiki's model). Covers toc_header(_level),
toc_link_format, links_header(_level), tags_header(_level),
html_header_numbering(_sym), links_space_char, list_margin, listsyms,
listsym_rejected, and the auto_* toggles. Only values the user
explicitly set fold — built-in defaults don't (added config.user
tracking on the Lua side so a default toc_header_level=1 isn't pushed
onto every wiki). User config tables are never mutated.
Both clients kept in lock-step (config-parity golden enforces identical
payloads). New harnesses test-vimwiki-compat-vim (18) and
test-global-shorthand (8), wired into CI. Server test
vimwiki_compat_payload_sets_toc_level_per_wiki. Docs in README +
known-issues.md (drop-in is currently Vim-only). Rust 573 passed, clippy
clean, all harnesses green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Promote known-issues.md to the authoritative divergence reference ahead
of retiring development/vimwiki-gap.md:
- drop the pointer into vimwiki-gap.md so the file stands alone
- reframe the intro as the single source of truth
- add an "Internal deferrals (non-parity)" section capturing the
cold-path optimizations (RSS render_entry_body disk read,
push_level_edit_for_line offset scan, diary neighbor scan) that
otherwise only lived in the gap doc, so nothing is lost on deletion
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Consolidate the deferred features and intentional divergences from the
parity log (development/vimwiki-gap.md) into a user-facing reference:
- Deferred: the markdown generated-content cluster
(markdown heading generation, markdown_header_style, markdown_link_ext)
- By-design divergences grouped by area (highlighting/conceal -> LSP,
syntax detection, config mechanism, auto_tags, mouse maps, list_margin
negative + diary_caption_level -1 value semantics, Vim/Win shims)
- Default-location differences (html_path/template_path/diary_rel_path)
- Notes on the vars.vim compat shim and additive commands
Link it from the README "Migrating from vimwiki" section so it's
discoverable.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gffranco