coc users had to hand-maintain a coc-settings.json `languageserver.nuwiki`
entry, which didn't track g:nuwiki_wikis / g:vimwiki_list / the global
shorthand and meant editing JSON per wiki. nuwiki now registers itself
programmatically: on the first .wiki buffer it calls
coc#config('languageserver.nuwiki', {…}) with the s:settings() payload
(same config the vim-lsp path sends). coc reacts to the languageserver
config change (onDidChangeConfiguration → registerClientsByConfig) and
starts the server for the open buffer.
Details:
- Reliable coc detection via :CocConfig (exists('*coc#config') can't be
trusted — it doesn't trigger autoload in Vim 9.2). The coc#config call
is wrapped in try/catch and autoloads coc.vim itself; falls back to the
printed snippet only if coc genuinely isn't there.
- Deferred to User CocNvimInit when coc's node service isn't up yet.
- Opt out with g:nuwiki_no_coc_register (then we just print the snippet).
Dogfooded in start-vim-coc.sh: dropped the manual coc-settings.json
languageserver block; the harness now relies on auto-registration from
g:nuwiki_* (real-user flow). New harness test-coc-register-vim (7 checks,
stubbed coc#config) asserts the injected payload incl. the folded global
shorthand; wired into CI. README coc section rewritten (zero-config).
Rust 573 passed, clippy clean, all harnesses green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The start-* dev harnesses generated a minimal server config (wiki_root,
file_extension, syntax, log_level, diagnostic) with no display settings,
so :NuwikiTOC always produced `= Contents =` (level 1) regardless of code
changes — there was no way to test toc_header_level/html numbering through
the harness. The coc launcher is worst: coc reads coc-settings.json
verbatim, bypassing the Vim client's config translation entirely.
Set toc_header_level=2, html_header_numbering=2, html_header_numbering_sym
in all three launchers:
- start-vim-coc.sh: into the generated coc-settings.json (init + settings).
- start-vim.sh: as g:nuwiki_* globals (folded into the wiki via the global
shorthand).
- start-nvim.sh: in the setup() table.
Now the dev wiki demonstrates the settings: :NuwikiTOC writes
`== Contents ==` and HTML export numbers headings.
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>
The parity work stream is complete. Forward-looking content (vimwiki
divergences, deferred features, internal deferrals) now lives in the
single source of truth, known-issues.md; the historical per-item
tracking log is preserved in git history. No code or docs reference the
file.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Implements the deferred half of these options: a soft line break inside a
paragraph / list item can render as <br /> instead of a space.
- Parser: soft breaks now emit a dedicated InlineNode::SoftBreak node
(parse_inline_seq K::Newline + the list-continuation synthetic join) instead
of collapsing to Text(" "). Added SoftBreakNode + the variant.
- All inline consumers treat SoftBreak as whitespace: AST visitor (no-op),
text extraction (index.rs + lib.rs → space), nav/semantic_tokens span_of_inline,
semantic emit (skip like Text), parser span_of_inline.
- Renderer: render_inlines_break renders top-level SoftBreaks as the
context-specific string; render_paragraph uses text_ignore_newline,
render_list_item uses list_ignore_newline; default render_inline → space.
with_newline_handling builder; export.rs wires both from HtmlConfig.
Default (true/true = upstream default) behaviour is unchanged (space). Updated
3 core tests + 1 parser test that asserted the old Text(" ") shape to treat
SoftBreak as whitespace. New test render_page_html_ignore_newline_controls_soft_breaks.
Gap doc: P3 Config item closed — only the deferred markdown cluster remains.
Full rust suite + clippy clean; Neovim 307, Vim 301/18/21.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- create_link (default true): server resolve_target_uri now only synthesises a
missing-page URI when create_link is set; when off, following a link to a
non-existent page returns no location (no-op).
- dir_link: a [[dir/]] link now resolves to <dir>/<dir_link><ext> when dir_link
is set, else opens the directory itself. Uses the already-parsed
LinkTarget.is_directory.
- auto_header (default off): new wiki pages get a `= Stem =` header derived from
the filename, skipping the wiki index + diary index. Client-side BufNewFile
autocmd in both clients (init.lua + plugin/nuwiki.vim), with auto_header
handlers in both command layers (trailing-slash-robust root matching).
Tests: cmd.auto_header_inserts + cmd.auto_header_skips_diary_index (nvim) /
cmd.auto_header_skips_index (vim). Full rust suite + both harnesses green
(Neovim 307, Vim 301/18/21).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The mappings re-audit confirmed the two new bindings (visual <CR> normalize,
insert <S-CR> multiline item) are correct — column math matches upstream's
s:text_begin, auto-indent handling sound, no parity gaps or regressions.
It flagged one low-severity item shared with the pre-existing smart_return:
neither guarded the completion popup. Upstream maps <CR>/<S-CR> as
`pumvisible() ? '<CR>' : …`. Added that guard to both smart_return and
smart_shift_return (both clients) so a <CR>/<S-CR> accepts the completion
instead of continuing the list when the popup is open.
Left as a documented minor divergence: <S-CR> on an *empty* bullet emits the
aligned no-marker continuation rather than upstream's "blank line above, keep
marker" (niche). Neovim 305, Vim 299/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Both remaining mapping gaps (client-side, both clients):
- Visual <CR>: upstream binds it to NormalizeLinkVisualCR (== visual `+`).
Added `x <CR>` -> normalize_link(true) (wrap the selection as a wikilink)
in both clients.
- Insert <S-CR>: upstream's multiline-list-item continuation (VimwikiReturn
2 2 -> kbd_cr with no new marker). New smart_shift_return (both clients,
<expr> insert mapping): on a list item returns <CR> + spaces aligning under
the item text (marker width + 1, +4 for a `[ ] ` checkbox), no marker; off a
list item, a plain <CR>. Mirrors smart_return's auto-indent handling.
Tests: map.visual_cr_wraps_selection + map.insert_shift_cr_multiline
(test-keymaps.lua, the latter exercising the handler directly since <S-CR>
doesn't round-trip headless feedkeys), and map.visual_cr_wraps_selection +
cr.shift_cr_multiline{,_checkbox} (test-keymaps-vim.vim). Docs (README +
doc/nuwiki.txt) and the gap doc updated. Neovim 305, Vim 299/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Re-audit of the just-landed command work found one real bug I introduced
and a convention gap:
- VimwikiSearch / VWS raised a raw E480 on a no-match search; upstream
reports it gracefully. Both clients now catch it (try/catch in Vim,
pcall in Neovim) and emit "nuwiki: no match for <pat>".
- Added a NuwikiSearch alias alongside VimwikiSearch/VWS (every other
command carries a Nuwiki* form).
Gap-doc note corrected: nuwiki's search populates + opens the location
list (shows all matches) where upstream jumps to the first match — logged
as a minor presentation divergence rather than claiming exact parity.
Config + mappings re-audits came back clean (no new gaps, no regressions;
table-mapping rewire verified non-recursive, gLH/gLL/gLR present).
Tests: cmd.VimwikiSearch_no_match_graceful, surface.{Vimwiki,Nuwiki}Search.
Neovim 301, Vim 294/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
All six remaining command gaps (client-side; no server change):
- VimwikiRenameFile: bare -> -nargs=? (arg accepted-ignored; rename still
delegates to the LSP rename prompt). No more E488.
- VimwikiVar / NuwikiVar: get/set the client config (upstream vimwiki#vars#cmd).
No arg prints config (Vim: g:nuwiki_*; Neovim: resolved setup() opts), one arg
gets a key, two+ sets it. Global command, both clients.
- VimwikiReturn / NuwikiReturn: command form of the smart <CR> continuation —
enters insert at EOL and fires the <CR> mapping (return_cmd / vimwiki_return).
Upstream's mode-flag args accepted but unused.
- VimwikiTableAlignQ vs AlignW: corrected — upstream's gqq/gww are identical on
a table; the only difference is the non-table fallback (native `normal! gqq`
vs `gww`). New table_align_or_cmd(cmd) aligns on a table row, else runs
`normal! <cmd>`. Q/gqq/gq1 -> gqq; W/gww/gw1 -> gww; NuwikiTableAlign -> gqq.
- VimwikiSearch / VWS: scope the lvimgrep to the current wiki's root (resolved
client-side) over <root>/**/*<ext>, not CWD `**`; empty pattern reuses the
last search. Both clients.
- VimwikiIndex family: add global Vimwiki/NuwikiIndex + TabIndex entry points
(plugin/nuwiki.vim + init.lua _setup_global_commands, with -count), so a wiki
opens from any buffer. Buffer-local copies still shadow inside wiki buffers.
Tests: surface.{Vimwiki,Nuwiki}{Return,Var}, cmd.VimwikiVar_sets_*,
cmd.global_entry_points (both harnesses). Docs (README + doc/nuwiki.txt) and the
gap doc updated. Neovim 299, Vim 291/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes the actionable fifth-pass findings (gap doc updated):
- VimwikiGoto / NuwikiGoto: -nargs=1 -> -nargs=* in all four defs. Was a
real bug — `:VimwikiGoto` raised E471, `:VimwikiGoto My Page` raised E488,
and the handler's empty-arg prompt fallback was unreachable. Both clients
already prompt on empty, so -nargs=* (keeping -complete=pages) restores
upstream behavior.
- autowriteall (upstream default ON): while a wiki buffer is current, mirror
Vim's global 'autowriteall' (auto-save on page switch / :make), restoring
the prior value on leave. Neovim via ftplugin.lua setup_autowriteall
(BufEnter/BufLeave) gated by the `autowriteall` setup option; Vim via the
NuwikiAutoWriteAll augroup gated by g:nuwiki_autowriteall.
- table_auto_fmt (upstream default ON): re-align the table under the cursor
on InsertLeave. Both clients, gated by `table_auto_fmt` / g:nuwiki_table_auto_fmt,
guarded on the cursor line containing `|` before the async table_align.
Also logged (no code): VimwikiRenameFile missing -nargs=? (subsumed by the
LSP-rename divergence), table_reduce_last_col, user_htmls, hl_headers/
hl_cb_checked, and a commentstring value-mismatch note. Mappings audit clean.
The Neovim harness disables table_auto_fmt in setup (its async re-align would
perturb the deterministic table-nav keystroke cases); its wiring is verified
on a throwaway scratch buffer instead. Docs (README + doc/nuwiki.txt) updated.
Tests: cmd.VimwikiGoto_accepts_multiword, config.autowriteall_applied,
config.table_auto_fmt_autocmd. Neovim 293, Vim 285/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes four low-risk P3 parity items (gap doc updated):
- VimwikiShowVersion / NuwikiShowVersion: new global command (both clients)
echoing g:nuwiki_version (0.1.0) + the host editor, via
nuwiki#commands#show_version / commands.show_version.
- gLH / gLL / gLR: upstream's case-variant aliases of gLh/gLl/gLr (dedent /
indent whole item, renumber all lists) added in both clients.
- VimwikiSearch / VWS: -nargs=1 -> -nargs=* (Vim + Neovim), so a multi-word
search no longer raises E488 and an empty invocation reuses the last search
pattern. (The lvimgrep-vs-vimwiki-engine difference stays open.)
- VimwikiTableAlignQ / AlignW / NuwikiTableAlign: bare -> -nargs=?, so
`:VimwikiTableAlignQ 2` no longer raises E488 (optional column arg is
accepted-and-ignored; the gqq-align vs gww-align-without-resize split
stays open).
Docs (doc/nuwiki.txt + README) updated for the command and the aliases.
Tests: surface.{Vimwiki,Nuwiki}ShowVersion, map[n].gL{H,L,R} (both
harnesses), cmd.search_and_tablealign_nargs (vim). Neovim 291, Vim
282/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implements the remaining fourth-pass findings (gap doc updated):
- list_margin: rework to upstream's buffer-side meaning. Drop the
nuwiki-only HTML em-margin (renderer field/method + render_page_html
param removed) and prepend max(0, list_margin) leading spaces to every
generated bullet in build_toc_text / build_links_text /
build_tag_links_text / diary::build_index_body; headings stay at col 0.
From<RawWiki> derives 0 for markdown wikis when unset. Negatives can't
resolve 'shiftwidth' server-side, so they collapse to zero indent
(documented divergence).
- diary_months: per-wiki Vec<String> (default 12 English names), threaded
into the diary-index month labels; missing/empty slots fall back to the
English name.
- diary_caption_level: widen u8 -> i8 so vimwiki's -1 (min: -1) parses;
build_index_body clamps < 0 to base tree level 0.
- VimwikiRemoveDone: regain upstream's -range. All four defs are now
-bang -range, dispatched via remove_done(bang, range, l1, l2) in both
clients: ! -> whole buffer, explicit range -> new list_remove_done_range
({range:[l1-1,l2-1]}), else current list. Server remove_done_edit gained
an Option<(u32,u32)> range that filters whole-doc victims by start line.
markdown_header_style is deferred: the generators emit vimwiki syntax only
(caption_line never writes markdown headers), so there's no markdown header
to attach the style to. Logged as the "generated-content is vimwiki-only"
intentional divergence pending a later markdown generated-content effort.
Tests: list_margin indent, markdown list_margin-0 default, diary_months
custom + fallback, negative caption_level clamp/parse, ranged remove-done
(server + both keymap harnesses). 553 lsp/core tests pass; clippy clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Upstream's :VimwikiToggleRejectedListItem is -range and binds glx in
visual mode; nuwiki's four defs were bare, so a ranged invocation raised
E481 and acted cursor-only. Same -range class already fixed for
ToggleListItem/Increment/Decrement -- ToggleRejected was missed.
All four defs (Vim+Neovim x Vimwiki*/Nuwiki*) are now -range, routed
through a new reject_list_item_range(l1, l2) looping over_range in both
clients, mirroring toggle_list_item_range. Visual glx stays cursor-only,
consistent with its <C-Space>/gln/glp siblings.
Also logs the 2026-06-02 re-audit findings in development/vimwiki-gap.md:
RemoveDone lost -range (low pri); config gaps list_margin
semantics/markdown-default, diary_months, markdown_header_style,
diary_caption_level=-1; and the path_html/template_path default-location
divergences. Mappings audit came back clean.
Tests: cmd.reject_list_item_range (test-keymaps.lua),
cmd.VimwikiToggleRejectedListItem_accepts_range (test-keymaps-vim.vim).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- diary.vim: correct calendar_action doc comment (dir is used for split
direction; only week is unused)
- calendar-vim-integration.md: use real nuwiki var names
(g:nuwiki_use_calendar / g:nuwiki_no_calendar / g:nuwiki_wikis), document
auto-detect wiring and calendar-window close behavior; drop the
non-existent refresh-on-close autocmd
- vimwiki-gap.md: remove stale 'no calendar.vim integration' entry now
that the integration is implemented
Add headless harnesses covering the calendar-vim integration, wired into
CI alongside the existing keymap/config suites:
- test-calendar-vim.sh/.vim (+ -optout.vim): pure-VimL diary hooks
(calendar_sign markers, calendar_action path resolution from wiki root,
calendar window close), plugin/nuwiki.vim hook auto-wiring that
overrides calendar-vim's defaults, and opt-out via g:nuwiki_use_calendar
and g:nuwiki_no_calendar. Uses a stub calendar-vim on the runtimepath.
- test-calendar.sh/.lua: Neovim setup() wiring + window-close under the
real window API, and opt-out via use_calendar = false.
Fixes surfaced by the suite:
- diary.vim: new diary entries set filetype 'vimwiki' (was the raw
extension, e.g. 'wiki'); the stray FileType autocmd also blocked the
calendar window from closing.
- init.lua: drop the redundant Neovim FileType autocmd (plugin/nuwiki.vim
already wires both editors) and translate use_calendar=false into
g:nuwiki_no_calendar so the opt-out actually disables wiring.
Wire g:calendar_action/g:calendar_sign to nuwiki diary hooks that
resolve diary paths from the wiki root config instead of calendar-vim's
default ~/diary. Auto-detected on FileType vimwiki when calendar-vim is
present; opt out with g:nuwiki_use_calendar=0 or g:nuwiki_no_calendar.
- autoload/nuwiki/diary.vim: calendar_action/calendar_sign using wiki cfg;
open diary in the previous window and close the calendar window after.
- autoload/vimwiki/diary.vim: vimwiki# aliases for drop-in compatibility.
- plugin/nuwiki.vim + lua/nuwiki/init.lua: auto-wire hooks, overwriting
calendar-vim's defaults while respecting user-set custom hooks.
- lua/nuwiki/config.lua: add use_calendar option (on by default).
- development/start-*.sh + _common.sh: clone calendar-vim, fix vimrc var
expansion, pass wiki root to the Vim/Neovim clients.
2da2168's diary test edits landed unevenly: the lua
cmd.VimwikiMakeDiaryNote_has_count case got inserted twice, and the two vim
cases (cmd.Vimwiki{MakeDiaryNote,DiaryIndex}_accepts_count) the commit message
referenced never landed (the Edit had no-matched). Remove the lua duplicate and
add the two vim cases before the harness wrap-up. lua 284, vim 274/18/21, all
0 failed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
874bdd0 committed the diary -count feature with several Edits that had
silently no-matched, leaving the tree non-compiling and the clients
inconsistent (CI run 236 failed). This completes it:
- commands.rs: add the `wiki` field to OptionalUriArg (the previous edit
targeted a wrong struct name) and pass None to the six resolve_diary_wiki
callers that take no selector (date/list/step paths). Server builds clean.
- autoload/nuwiki/commands.vim + lua/nuwiki/commands.lua: actually thread the
count through s:diary_open / _diary_open and the diary_today/today_tab/
yesterday/tomorrow/index handlers (these edits had failed before, so the
ftplugin defs were calling handlers that ignored/rejected the arg).
- Add the test cases the prior commit referenced but never landed:
cmd.VimwikiMakeDiaryNote_has_count (test-keymaps.lua) +
cmd.Vimwiki{MakeDiaryNote,DiaryIndex}_accepts_count (test-keymaps-vim.vim).
- Fix the OptUriArg→OptionalUriArg name in the gap-doc note.
Verified with CI flags: workspace test/clippy/fmt clean; lua 284, vim 272/18/21,
all 0 failed; the three new diary cases pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes the last command-cluster gap. Upstream's diary-note family
(:Vimwiki{Make,TabMake,MakeYesterday,MakeTomorrow}DiaryNote + VimwikiDiaryIndex,
and the Nuwiki* forms) carry -count=0 where the count selects the wiki number;
nuwiki's were bare. Implemented as a real end-to-end selector, reusing existing
infrastructure:
- Server (commands.rs): OptUriArg gained an optional `wiki` selector;
resolve_diary_wiki(backend, uri, wiki) now prefers it (via the existing
resolve_wiki_selector, which already handles a 0-indexed wiki number) over
the buffer URI. Used by diary_open_relative + diary_open_index.
- Clients: s:diary_open / _diary_open (both) and diary_today/today_tab/
yesterday/tomorrow/index take a count and send {wiki: count-1} when >0. All
22 diary-note + DiaryIndex command defs across the 4 contexts are now
-count=0 passing <count>. diary_next/prev ignore the count.
Tests: cmd.VimwikiMakeDiaryNote_has_count (test-keymaps.lua) +
cmd.Vimwiki{MakeDiaryNote,DiaryIndex}_accepts_count (test-keymaps-vim.vim).
Workspace test/clippy/fmt clean with CI flags; lua 284, vim 272/18/21.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes the three new command gaps from the 2026-05-31 re-audit (all real,
client-side, both clients x Vimwiki/Nuwiki):
- VimwikiChangeSymbolTo / ListChangeSymbolI / NuwikiChangeSymbol are now
-range -nargs=1 via a new list_change_symbol_range(symbol,l1,l2) helper that
loops over_range; was -nargs=1 only -> E481 on a visual selection.
ChangeSymbolInListTo / ChangeSymbolInList stay range-less and keep
whole_list=true.
- VimwikiGenerateLinks / NuwikiGenerateLinks are now -nargs=?; with an arg the
client dispatches the existing server command nuwiki.links.generateForPath
({path}) for real subtree-scoped link generation, else nuwiki.links.generate.
Was bare -> E488 on an arg.
- Added NuwikiGenerateTags (Vim + Neovim) mirroring VimwikiGenerateTags, with
-nargs=? -complete=...tags - closes the :Vimwiki*<->:Nuwiki* alias asymmetry.
Tests: cmd.ChangeSymbolTo_range_sets_marker, cmd.GenerateLinks_accepts_optional_path,
cmd.NuwikiGenerateTags_exists (test-keymaps.lua, 283 pass) +
cmd.VimwikiChangeSymbolTo_accepts_range, cmd.VimwikiGenerateLinks_accepts_path,
cmd.NuwikiGenerateTags_exists (test-keymaps-vim.vim, 272/18/21). fmt clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes the three new command gaps from the 2026-05-31 re-audit (all real,
client-side, both clients × Vimwiki/Nuwiki):
- VimwikiChangeSymbolTo / ListChangeSymbolI / NuwikiChangeSymbol are now
-range -nargs=1 via a new list_change_symbol_range(symbol,l1,l2) helper that
loops over_range; was -nargs=1 only → E481 on a visual selection.
ChangeSymbolInListTo/InList stay range-less.
Bonus: the Neovim VimwikiChangeSymbolInListTo + NuwikiChangeSymbolInList defs
passed whole_list=false, changing only the current item — corrected to true.
- VimwikiGenerateLinks / NuwikiGenerateLinks are now -nargs=?; with an arg the
client dispatches the existing server command nuwiki.links.generateForPath
({path}) for real subtree-scoped link generation, else nuwiki.links.generate.
Was bare → E488 on an arg.
- Added NuwikiGenerateTags (Vim + Neovim) mirroring VimwikiGenerateTags, with
-nargs=? -complete=…tags — closes the :Vimwiki*↔:Nuwiki* alias asymmetry.
Tests: cmd.ChangeSymbolTo_range_sets_marker, cmd.GenerateLinks_accepts_optional_path,
cmd.NuwikiGenerateTags_exists (test-keymaps.lua, 283 pass) +
cmd.VimwikiChangeSymbolTo_accepts_range, cmd.VimwikiGenerateLinks_accepts_path,
cmd.NuwikiGenerateTags_exists (test-keymaps-vim.vim, 272/18/21). fmt clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three parallel audits (commands/mappings/configs) re-verified all recent fixes
PASS across every context and surfaced new command-attribute gaps, each
confirmed against the code:
New P3 command gaps:
- VimwikiChangeSymbolTo / VimwikiListChangeSymbolI lack -range (upstream has it)
→ E481 on a visual selection.
- VimwikiGenerateLinks lacks -nargs=? (upstream optional rel-path arg) → E488.
- NuwikiGenerateTags missing (Vimwiki form + NuwikiGenerateTagLinks exist) —
:Vimwiki*↔:Nuwiki* asymmetry.
Refinements to existing P3 items:
- TableAlignQ/W: also bare vs upstream -nargs=? (E488 with an arg).
- VimwikiSearch/VWS: also -nargs=1 vs upstream -nargs=*.
- diary -count: VimwikiDiaryIndex is an additional instance to fold in.
- color_dic: note the empty-default vs upstream-palette divergence (doc-accurate,
not a doc↔code mismatch) next to color_tag_template.
Mappings + configs audits: clean — no new gaps, all recent work consistent,
subgroup descriptions match code. Tally now 30 done / 27 open (all P3).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The previous commit's test-insert Edit silently no-matched (wrong anchor
text), so cmd.VimwikiFollowLink_wraps_bare_word and
cmd.VimwikiSplitLink_wraps_bare_word were referenced in the commit message and
gap doc but never added. Add them now at the correct anchor; the lua harness
goes 278 → 280, both new cases pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Audit follow-up on the two link-path items flagged during the command-attribute
pass:
- REAL (bug #2): all eight Neovim Ex-command link defs (Vimwiki/Nuwiki ×
FollowLink/SplitLink/VSplitLink/TabnewLink) dispatched to raw
`lua vim.lsp.buf.definition()`, bypassing the bare-word → [[link]] wrap +
create-on-follow that the Vim commands and the Neovim <CR> family already do.
All eight now call follow_link_or_create() (keeping their split/vsplit/tabnew
prefixes). TabDropLink already used follow_link_drop and is unchanged.
- FALSE ALARM (bug #1): the audit's claim that lua follow_link_or_create was
"botched" (double definition() with dead pos_args code, no wrap) was a
mis-read — it was a single correct definition that already wrapped bare words
and is dispatched by <CR>. Tidied anyway: collapsed its two definition() call
sites into one tail call; behaviour is identical (wrap still skipped when
already inside a link, via short-circuit).
Tests: cmd.VimwikiFollowLink_wraps_bare_word + cmd.VimwikiSplitLink_wraps_bare_word
(test-keymaps.lua). Both harnesses green (lua 280, vim 269/18/21, 0 failed);
gap doc corrected for both entries.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Upstream attaches -complete= to several commands; nuwiki had none, so <Tab>
at the : line never completed page/tag/colour names. New
autoload/nuwiki/complete.vim adds pure client-side, synchronous completers
(config + filesystem, never the LSP — so they work under vim-lsp, coc and
Neovim), wired via -complete=customlist into all command contexts:
- nuwiki#complete#pages → VimwikiGoto/NuwikiGoto (glob wiki roots for page names)
- nuwiki#complete#colors → VimwikiColorize/NuwikiColorize (color_dic keys +
colours already used in buffer color:… spans)
- nuwiki#complete#tags → VimwikiSearchTags/GenerateTagLinks/GenerateTags (+Nuwiki)
(scan wiki files for :tag: runs — the tag index is server-side and a
synchronous completer can't query it, so we read the same source it indexes)
Documented divergence: no file completer for VimwikiRenameFile — nuwiki
delegates renaming to the LSP rename request (no filename arg to complete),
unlike upstream which renames itself.
Tests: complete.{pages_globs_and_filters,tags_scans_wiki_files,
colors_from_buffer_spans} (test-keymaps-vim.vim). Both harnesses green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Verification audit of the command-attribute pass confirmed all four changes
(Table, Index/TabIndex, ListChangeLvl, SplitLink) faithful with no regressions,
and surfaced three pre-existing items:
- VimwikiTable no-arg default cols was 3 vs upstream's 5 (rows 2 already
matched, confirmed against vimwiki#tbl#create). Aligned both backing fns
(autoload + lua) to default 5 cols.
- Mapped (not fixed here — core <CR> behavior, out of attribute scope):
the Neovim lua follow_link_or_create double-calls definition() with dead
code and never wraps a bare word into [[link]] (the Vim side does); and the
Neovim Split/VSplitLink dispatch to raw definition() instead of
follow_link_or_create. Both logged in development/vimwiki-gap.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Upstream's :Vimwiki[V]SplitLink take optional reuse_other_split_window +
move_cursor flags (the link is always the one under the cursor); nuwiki's defs
took no args, so `:VimwikiSplitLink 0 1` raised E488. All eight defs (both
clients × Split/VSplit × Vimwiki/Nuwiki) are now -nargs=*, restoring signature
parity for migrated configs/scripts.
Documented divergence: the two flags are accepted but not acted on — nuwiki
always opens a fresh split and follows in it. Honoring move_cursor/reuse would
require threading a completion callback through the async LSP follow path,
disproportionate for this rarely-used arg form; the no-arg path (99% case) is
fully equivalent. The gap-doc note (which wrongly described the args as a
"target link") is corrected.
Test: cmd.VimwikiSplitLink_accepts_args (test-keymaps-vim.vim, no E488).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Upstream is `-range -nargs=+` (change_level(line1, line2, direction,
plus_children)); nuwiki was -nargs=? and range-less, so `:1,3VimwikiListChangeLvl
increase 0` raised E481/E488 and the level change never spanned a selection.
All four defs (Vim+Neovim × Vimwiki+Nuwiki) are now -range -nargs=+ and forward
<line1>, <line2>, <f-args>. list_change_lvl(line1, line2, direction,
[plus_children]) (both clients) parses the required direction + optional subtree
flag and applies the change to every list item in the range via the existing
over_range helper.
Tests: cmd.ListChangeLvl_range_indents (test-keymaps.lua) +
cmd.VimwikiListChangeLvl_accepts_range_and_args (test-keymaps-vim.vim).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two command-attribute parity fixes (audited against upstream vimwiki master):
- VimwikiTable / NuwikiTable were -nargs=1 and called table_insert() with no
args, so `:VimwikiTable 4 3` raised E488 and cols/rows were unreachable.
All four defs (Vim+Neovim × Vimwiki+Nuwiki) are now -nargs=* and forward
<f-args>; the backing table_insert already parsed cols (a:1) + rows (a:2).
- VimwikiIndex/TabIndex (and Nuwiki forms) switch from bare -count to
upstream's -count=0. Behavior is unchanged (both default count to 0;
wiki_index already maps a count to the 1-indexed wiki number) — this just
matches the upstream declaration exactly.
Tests: cmd.VimwikiTable_passes_cols_and_rows (test-keymaps.lua — asserts a
4-col/3-row table) and cmd.VimwikiTable_accepts_cols_rows (test-keymaps-vim.vim
— no E488). gap doc updated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A map_prefix parity audit against upstream vimwiki found the Neovim global
entry-point block in lua/nuwiki/init.lua carried the same collision the Vim
global + buffer-local maps were already fixed for: <prefix><Leader>t was
bound to tomorrow and <prefix><Leader>m (tomorrow) was missing entirely.
Now <prefix><Leader>t opens today in a new tab and <prefix><Leader>m is
tomorrow — consistent with plugin/nuwiki.vim, the buffer-local maps, and
upstream (VimwikiTabMakeDiaryNote / VimwikiMakeTomorrowDiaryNote).
Adds global_maps.diary_tab_and_tomorrow_targets to test-keymaps.lua (queries
in a scratch buffer so buffer-local maps don't shadow the globals). Logs the
fix plus a new "RSS feed structure fidelity" gap (the audit confirmed the
custom_wiki2html arg contract and base_url scope are faithful; only the RSS
document shape diverges) in development/vimwiki-gap.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mirror vimwiki's g:vimwiki_map_prefix. The whole <Leader>w* family was
hardcoded across the map layer; it is now built from a configurable prefix:
- Neovim: `map_prefix` setup() option (default '<Leader>w'), read by
lua/nuwiki/keymaps.lua (buffer-local) and lua/nuwiki/init.lua (global
entry points).
- Vim: g:nuwiki_map_prefix, applied via :exe in plugin/nuwiki.vim (global)
and ftplugin/vimwiki.vim (buffer-local).
Setting a custom prefix relocates <prefix>{w,t,s,i,n,d,r,c,h,hh,ha} and
<prefix><Leader>{w,y,t,m,i}, leaving nothing under the old <Leader>w*.
Non-prefix maps (<CR>, gl*, headers, …) are untouched.
Tests: new test-keymaps-vim-prefix.vim harness (21 cases, wired into
test-keymaps-vim.sh) + map_prefix.relocates_wiki_family in test-keymaps.lua.
Docs: README, doc/nuwiki.txt, lua config comment, vimwiki-gap.md ticked.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add three per-wiki HtmlConfig keys mirroring vimwiki globals:
- custom_wiki2html / custom_wiki2html_args: when set, export shells out
to the external converter via `sh -c` with vimwiki's exact arg order
(<cmd> <force> <syntax> <ext> <out_dir> <in_file> <css> <tpl_path>
<tpl_default> <tpl_ext> <root_path> <args>, `-` for empty optionals)
instead of the built-in renderer.
- base_url: when set, diary RSS item + channel links become
<base_url><diary_rel_path>/<date>.html instead of file:// URIs.
write_page() gains a `force` flag threaded through export_current (false),
export_all (its own flag) and the did_save auto-export path (false).
Tests: write_page_invokes_custom_wiki2html_converter,
write_rss_uses_base_url_for_public_links (html_export.rs), config
round-trip + defaults (index_and_config.rs). Docs: README, doc/nuwiki.txt,
lua config comment, vimwiki-gap.md item ticked.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Added per-wiki auto_generate_links, auto_generate_tags, auto_diary_index
(default false, like upstream), wired into the did_save hook mirroring
auto_toc:
- auto_generate_links / auto_generate_tags rebuild the Generated Links /
Generated Tags section ONLY when it already exists (new
links_rebuild_edit / tag_links_rebuild_edit, like toc_rebuild_edit) — never
inserts one into a page that lacks it.
- auto_diary_index regenerates the diary index page when a dated diary entry
(not the index itself) is saved, via diary_generate_index_edit (handles the
index file open / on-disk / absent).
auto_tags is recorded as an intentional divergence: nuwiki re-indexes tags on
every change, so the tag metadata is always fresh (no on-disk file to update).
Tests: links_rebuild_edit_only_acts_when_section_present,
tag_links_rebuild_edit_only_acts_when_index_present, config round-trip +
defaults. README/doc/lua comment updated. fmt/clippy clean; 0 Rust failures.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
TOC / links / tags section headings (and their levels) were hardcoded.
Added per-wiki toc_header/toc_header_level, links_header/links_header_level,
tags_header/tags_header_level — defaults Contents / Generated Links /
Generated Tags at level 1, matching upstream (also fixes the tags index
heading: Tags -> Generated Tags).
A caption_line(name, level) helper emits the `=`-markers; the configured
text + level thread through toc_edit / links_edit / tag_links_edit and the
auto_toc save hook. find_section_range matches the configured text, so
regeneration stays idempotent at any level.
Tests: captions_honour_custom_header_and_level (link_health) + config
round-trip + default assertions (index_and_config); existing tag/toc/links
tests updated for the new arity and the Generated Tags default. fmt/clippy
clean (8-arg ops get allow(too_many_arguments), matching the codebase
precedent); 0 Rust test failures; config-parity green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The rejected/cancelled checkbox glyph was a hardcoded `const REJECTED = '-'`.
ListSyms now carries a `rejected` field (new_with_rejected); a per-wiki
`listsym_rejected` key (default `-`) is added to WikiConfig, and
WikiConfig::list_syms() builds the palette with it. Routed the three
config-driven ListSyms construction sites (parse path in lib.rs + the
toggle/cycle commands) through list_syms(), so a custom rejected glyph both
lexes and round-trips.
Tests: listsyms::custom_rejected_glyph_is_honoured + config round-trip.
README/doc/lua config comment updated. fmt clean; 0 Rust test failures.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Third audit pass (config/mappings/commands vs vimwiki master) confirmed all
recent range/bang/visual and diary-week work is present and correct in both
clients, with no regressions, and that Neovim does bind the text objects.
It surfaced one real oversight: the Neovim Vimwiki/NuwikiIndex commands still
read vim.v.count (always 0 in command context) instead of <count> — the same
bug the TabIndex fix addressed, but Index was missed. Fixed both to <count>,
so :2NuwikiIndex now opens wiki 2.
Gap doc updated: new open item (VimwikiSplitLink/VSplitLink missing upstream
-nargs=*), mouse-maps-opt-in recorded as an intentional divergence, and the
third-pass summary. Suites green — nvim 274, vim 266+18.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implements the four items previously left as "needs handler work" — all
fully wired, not cosmetic.
- ToggleListItem / IncrementListItem / DecrementListItem are now -range
(both clients). The client loops the per-line op over [<line1>,<line2>]
(toggle_list_item_range / list_cycle_symbol_range). The server's edits are
version-less single-line WorkspaceEdits, so each line applies independently
— no server protocol change. `:'<,'>VimwikiToggleListItem` toggles the whole
selection.
- VimwikiRebuildTags gains -bang: `:…RebuildTags!` passes { all: true } and
the server (tags_rebuild) re-indexes every configured wiki via
wikis_snapshot(), not just the current one.
- VimwikiNormalizeLink is -nargs=?: with `1` (upstream's visual flag; the
x-mode `+` mapping now passes it) it wraps the '< / '> selection as
[[selection]] (new wrap_visual_as_wikilink in both clients).
- VimwikiCheckLinks is -range: a ranged invocation filters the broken-link
report to the current buffer's selected lines (client-side filter in
results_to_qf / check_links).
Tests: cmd.toggle_list_item_range + cmd.normalize_link_visual_wraps_selection
(test-keymaps.lua), normalize.visual_wraps_selection (test-keymaps-vim.vim).
README + doc/nuwiki.txt + gap doc updated. fmt/clippy clean; nvim 274,
vim 266+18, all Rust tests + config-parity green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Clean, fully-wired parity fixes (skipping the accept-but-ignore ones):
- <D-CR> (macOS Cmd+Return) → follow_link_drop, alongside <C-S-CR>, in both
clients. Upstream binds both to VimwikiTabDropLink.
- plugin/nuwiki.vim global map block: fix the same diary collision the
buffer-local maps had — <Leader>w<Leader>t now opens today in a new tab and
<Leader>w<Leader>m (tomorrow) is added.
- Neovim TabIndex: add -count to NuwikiTabIndex and switch both
Vimwiki/NuwikiTabIndex from vim.v.count (always 0 in command context) to
<count>, so a count is actually honored.
- Converge VimwikiTableMoveColumn{Left,Right}: the Vim-branch commands now call
the table_move_column_left/right aliases, matching the Neovim branch.
- VimwikiColorize/NuwikiColorize: -nargs=1 → -nargs=* (all four defs) for
upstream parity; a bare :VimwikiColorize now prompts for the colour.
Docs (README + doc/nuwiki.txt) updated; mapping surfaces gain <D-CR> and
<Leader>w<Leader>m in both harnesses. vim 265+18, nvim 272, all green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
c63ec67 dropped diary_start_week_day, hardwiring the weekly diary to ISO
(Monday) weeks. Upstream vimwiki instead names a weekly note by the
week-start day's date (YYYY-MM-DD) and honours diary_start_week_day. Rather
than force one scheme, make it a per-wiki choice so migrators keep upstream
behaviour while existing nuwiki weekly files keep working:
- New per-wiki key `diary_weekly_style`: `iso` (default — `YYYY-Www`,
Monday-based, nuwiki's original) or `date`/`vimwiki` (`YYYY-MM-DD` of the
week-start day, upstream parity).
- Restored per-wiki key `diary_start_week_day` (`monday`..`sunday`, default
monday); applies only in `date` mode.
Implementation:
- nuwiki-core::date gains WeeklyStyle, WeekStart, and DiaryCalendar (owns
today/next/prev — date-mode snaps to the week-start and steps ±7 days;
iso/daily/monthly/yearly defer to the existing DiaryPeriod logic).
- WikiConfig gains the two fields (+ defaults, RawWiki, From) and a
diary_calendar() builder; commands.rs diary_open_relative and the
next/prev pivot use it.
Defaults preserve current behaviour (iso/monday), so no breaking change.
Tests: DiaryCalendar cases in nuwiki-core/tests/diary.rs (snap, ±7, sunday
start, iso delegation, daily) + config round-trip in
nuwiki-lsp/tests/index_and_config.rs. README + doc/nuwiki.txt + lua config
comment updated. fmt + clippy clean; all crate tests + config-parity green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
nuwiki defaulted the per-wiki diary_caption_level to 1; upstream vimwiki's
default is 0 (year captions at the top level, months one below, rather than
nested one deeper). Default it to 0 in wiki_defaults(); still per-wiki
overridable. Render tests pass an explicit level so are unaffected; the
default-value assertion in defaults_carry_vimwiki_per_wiki_keys updated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Re-audited config / mappings / commands against vimwiki master with three
parallel agents. All recent P1/P2/P3 work confirmed present and correct in
both clients (no regressions). Logged new gaps the pass surfaced:
- P3 commands: diary-note family lacks -count (upstream -count=0); no
-complete= specs (page/tag/colour command-line completion); minor attribute
gaps (NormalizeLink -nargs=?, CheckLinks -range, Colorize -nargs=* vs 1).
- P3 mappings: <D-CR> (macOS Cmd+Return) tab-drop alias missing in both
clients; <Leader>w<Leader>m absent from the Vim *global* map block in
plugin/nuwiki.vim (present buffer-locally).
- Intentional divergences: global_ext (always-on via ftdetect) and the
syntax-default name (vimwiki vs default) noted so future audits skip them.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two upstream-parity keymap fixes (confirmed against upstream
ftplugin/vimwiki.vim):
1. <Leader>w<Leader>t collision — nuwiki bound both <Leader>w<Leader>t and
<Leader>w<Leader>m to tomorrow's diary. Upstream: <Leader>w<Leader>t opens
today's diary in a NEW TAB, <Leader>w<Leader>m opens tomorrow. <Leader>w
<Leader>t now calls diary_today_tab; <Leader>w<Leader>m stays tomorrow.
2. <M-CR> badd-link — adding a link target to the buffer list was mouse-only
(<MiddleMouse>) / command-only (:VimwikiBaddLink). Upstream binds
<M-CR> -> VimwikiBaddLink. Added normal-mode <M-CR> -> badd_link to the
links group of both clients.
Both clients (lua/nuwiki/keymaps.lua, ftplugin/vimwiki.vim); README + doc/
nuwiki.txt updated. Tests: map[n].<M-CR> in both harnesses;
diary.leader_t_opens_today_in_tab / diary.leader_m_opens_tomorrow (vim).
nvim 270, vim 263+18, all green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gffranco