fix(parity): close the 2026-06-02 re-audit config/command findings

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>

development/tests/test-keymaps-vim.vim

@@ -669,6 +669,26 @@ call s:record(
       \ 'cmd.VimwikiListChangeLvl_accepts_range_and_args',
       \ 'err=' . s:lcl_err)
 
+" ===== :VimwikiRemoveDone -bang -range =====
+" Upstream is `-range`; nuwiki had `-bang` only, so `:'<,'>VimwikiRemoveDone`
+" raised E481. Now `-bang -range`: a ranged invocation must parse (no E481),
+" and the `!` whole-buffer form must still work. The removal is an LSP
+" roundtrip (no server here), so assert only the attribute parse.
+call s:set_buf(['- [X] a', '- [ ] b', '- [X] c'])
+let s:rd_err = ''
+try
+  silent 1,2VimwikiRemoveDone
+  silent VimwikiRemoveDone!
+catch /E481/
+  let s:rd_err = v:exception
+catch
+  " non-E481 (e.g. no LSP attached) is expected and fine here.
+endtry
+call s:record(
+      \ s:rd_err ==# '' ? 1 : 0,
+      \ 'cmd.VimwikiRemoveDone_accepts_range_and_bang',
+      \ 'err=' . s:rd_err)
+
 " ===== :VimwikiToggleRejectedListItem -range =====
 " Was bare (range-less): `:1,3VimwikiToggleRejectedListItem` raised E481. The
 " reject is an LSP roundtrip (no server here), so assert only the attribute

development/tests/test-keymaps.lua

@@ -824,6 +824,21 @@ vim.defer_fn(function()
       error('range reject incomplete: ' .. vim.inspect(vim.api.nvim_buf_get_lines(0, 0, -1, false)))
     end
   end)
+  -- `:1,2VimwikiRemoveDone` — now -range (was -bang only → E481 on a ranged
+  -- invocation). Only done items within the range are removed; line-2 `[X]`
+  -- (0-indexed) outside [0,1] survives.
+  tobj_case('cmd.remove_done_range', function()
+    set_buf({ '- [X] a', '- [ ] b', '- [X] c' })
+    vim.cmd('1,2VimwikiRemoveDone')
+    local done = vim.wait(2000, function()
+      local ls = vim.api.nvim_buf_get_lines(0, 0, -1, false)
+      -- line-0 done item gone (2 lines left), line-2 done item still present.
+      return #ls == 2 and ls[#ls]:match('%[X%] c')
+    end, 30)
+    if not done then
+      error('ranged remove-done wrong: ' .. vim.inspect(vim.api.nvim_buf_get_lines(0, 0, -1, false)))
+    end
+  end)
   -- `:VimwikiTable {cols} [rows]` — now -nargs=* (was -nargs=1, which dropped
   -- the args entirely). A 4-col table has 5 pipes per row; 3 data rows give
   -- header + separator + 3 = 5 table lines.

development/vimwiki-gap.md

@@ -330,14 +330,20 @@ fix site.
   `gln`/`glp` siblings (the keymap-range question is a separate, family-wide
   item). Covered by `cmd.reject_list_item_range` (`test-keymaps.lua`) +
   `cmd.VimwikiToggleRejectedListItem_accepts_range` (`test-keymaps-vim.vim`).
-- [ ] **`VimwikiRemoveDone` dropped upstream's `-range`** _(new, 2026-06-02
-  re-audit)_ — upstream is `-range` (`ftplugin/vimwiki.vim:362`, "remove done
-  items in the selection"); nuwiki repurposed it to `-bang` only (the documented
-  redesign at the top of this doc), so `:'<,'>VimwikiRemoveDone` raises E481. The
-  `-bang` whole-buffer sweep is intentional; the lost `-range`/E481 is an
-  undocumented side effect. Low priority — decide whether to also accept a range
-  (filter the sweep to selected lines) or just note it as part of the documented
-  divergence.
+- [x] **`VimwikiRemoveDone` regained upstream's `-range`** _(new, 2026-06-02
+  re-audit; fixed 2026-06-02)_ — upstream is `-range` (`ftplugin/vimwiki.vim:362`,
+  "remove done items in the selection"); nuwiki had repurposed it to `-bang` only,
+  so `:'<,'>VimwikiRemoveDone` raised E481. _Fix:_ all four defs are now
+  `-bang -range`, dispatched by `nuwiki#commands#remove_done` /
+  `commands.remove_done(bang, range, l1, l2)` (both clients): `!` → whole-buffer
+  sweep (unchanged); an explicit range (`<range> > 0`, e.g. `:'<,'>`) → a new
+  `list_remove_done_range` sending `{range:[l1-1,l2-1]}`; otherwise the
+  cursor's current list. Server `remove_done_edit` gained an `Option<(u32,u32)>`
+  range that filters whole-doc victims by start line (`commands.rs`). Tests:
+  `remove_done_ranged_restricts_to_selected_lines` +
+  `remove_done_ranged_returns_none_when_range_has_no_done` (`commands_lists.rs`),
+  `cmd.remove_done_range` (`test-keymaps.lua`),
+  `cmd.VimwikiRemoveDone_accepts_range_and_bang` (`test-keymaps-vim.vim`).
 - [x] **`-complete=` specs** _(new; done 2026-05-31 command-attribute pass)_ —
   upstream attaches command-line completion to several commands; nuwiki had
   none, so `<Tab>` at the `:` line never completed page / tag / colour names.
@@ -382,36 +388,50 @@ fix site.
   `cmd.VimwikiSplitLink_accepts_args` (`test-keymaps-vim.vim`, no E488).
 
 ### Config
-- [ ] **`list_margin` — wrong semantics + wrong markdown default** _(new,
-  2026-06-02 re-audit)_ — upstream (`vars.vim:516`, doc `vimwiki.txt:2667`):
-  left-margin **width in spaces for buffer-side generated lists** — generated
-  links (`:VimwikiGenerateLinks`), the TOC, and the list-manipulation commands —
-  default `-1` (⇒ use `'shiftwidth'`) but **`0` for markdown** wikis
-  (`vars.vim:651`). nuwiki instead applies it **only** as an HTML CSS
-  `margin-left:<n>em` on the outermost `<ul>/<ol>` (`html.rs:337`) and never
-  indents the generated buffer content; it also defaults `-1` for all syntaxes
-  (`config.rs:417`), so markdown wikis get the wrong default. Two parts:
-  (a) the documented primary effect (buffer indentation in `build_links_text` /
-  TOC / `diary::build_index_body`) is absent; (b) derive `0` when
-  `syntax == "markdown"` and the key is unset. _(The HTML `em` reinterpretation
-  may have been deliberate — decide: implement buffer-side indent + markdown-0,
-  or keep the HTML meaning and document the divergence.)_
-- [ ] **`diary_months` — absent (month names hardcoded)** _(new, 2026-06-02
-  re-audit)_ — upstream global (`vars.vim:141`) maps month numbers → names for
-  the generated diary-index tree; nuwiki hardcodes English in `diary.rs`
-  `month_name()`. i18n only — low. _Fix:_ optional `diary_months` map on
-  `RawWiki`/`WikiConfig`, threaded into `build_index_body`'s month labels.
-- [ ] **`markdown_header_style` — absent** _(new, 2026-06-02 re-audit)_ —
-  upstream global (`vars.vim:174`, default `1`): number of blank lines inserted
-  after a **generated** header in markdown syntax (generated links, TOC, tags,
-  diary index). nuwiki's `caption_line` (`commands.rs`) emits no configurable
-  trailing blank line. Cosmetic, markdown-only.
-- [ ] **`diary_caption_level = -1` not representable** _(new, 2026-06-02
-  re-audit)_ — upstream allows `-1` ("read no headers from diary pages",
-  `vars.vim:507` `min: -1`); nuwiki types the field as `u8` (`config.rs`,
-  `RawWiki`), so a `-1` config fails deserialization and silently falls back to
-  `0`. The *default* (`0`) is correct — only the `-1` value is lost. _Fix:_ widen
-  to `i8` (and honour `-1` if/when caption-from-page-headers lands). Edge case.
+- [x] **`list_margin` — buffer-side parity + markdown default** _(new,
+  2026-06-02 re-audit; fixed 2026-06-02)_ — upstream (`vars.vim:516`, doc
+  `vimwiki.txt:2667`): left-margin **width in spaces for buffer-side generated
+  lists** — generated links (`:VimwikiGenerateLinks`), the TOC, the tags index,
+  and the diary index — default `-1` but **`0` for markdown** wikis
+  (`vars.vim:651`). nuwiki had instead applied it **only** as an HTML CSS
+  `margin-left:<n>em`. _Fix (true-parity, chosen over keeping the HTML meaning):_
+  dropped the HTML `em`-margin entirely (renderer `list_margin` field/method +
+  the `render_page_html` param removed) and now 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` (the
+  TOC keeps its per-depth nesting after the base margin); headings stay at
+  column 0. `From<RawWiki>` derives `0` for markdown wikis when the key is unset.
+  **Divergence (documented in the field doc):** upstream resolves a negative
+  value to the buffer's `'shiftwidth'`, which the server can't observe, so
+  negatives collapse to zero indent (matches nuwiki's prior default output).
+  Tests: `list_margin_indents_generated_bullets_not_headings` (`link_health.rs`),
+  `markdown_wiki_derives_list_margin_zero_when_unset` (`index_and_config.rs`).
+- [x] **`diary_months`** _(new, 2026-06-02 re-audit; fixed 2026-06-02)_ —
+  upstream global (`vars.vim:141`) maps month numbers → names for the generated
+  diary-index tree; nuwiki hardcoded English. _Fix:_ per-wiki `diary_months:
+  Vec<String>` (default the 12 English names) on `WikiConfig`/`RawWiki`, threaded
+  into `build_index_body`; a missing/empty slot falls back to the English
+  `month_name`. Tests: `build_index_body_uses_custom_diary_months` +
+  `…_falls_back_per_missing_month_slot` (`diary.rs`), config round-trip
+  (`index_and_config.rs`).
+- [ ] **`markdown_header_style`** _(new, 2026-06-02 re-audit; deferred)_ —
+  upstream global (`vars.vim:174`, default `1`): blank lines after a **generated**
+  header in markdown syntax. **Intentionally deferred:** nuwiki's generators
+  emit vimwiki syntax only (`caption_line` always writes `= H =`, never `# H`),
+  so there's no markdown header to attach the style to yet. This is part of a
+  broader "markdown generated-content" gap — markdown-style heading generation
+  comes first, then this blank-line control on top. See the divergence note
+  below.
+- [x] **`diary_caption_level = -1` now representable** _(new, 2026-06-02
+  re-audit; fixed 2026-06-02)_ — upstream allows `-1` (`vars.vim:507` `min: -1`);
+  nuwiki had typed the field as `u8`, so a `-1` config failed deserialization
+  and silently fell back to `0`. _Fix:_ widened to `i8` across
+  `WikiConfig`/`RawWiki`/`WikiDefaults`; `build_index_body` clamps `< 0` to a
+  base tree level of `0`. (nuwiki builds the index tree from dates, so upstream's
+  `-1` = "no per-page captions" semantic doesn't apply — it just clamps; noted in
+  the field doc.) Tests: `diary_caption_level_accepts_negative`
+  (`index_and_config.rs`), `build_index_body_clamps_negative_caption_level_to_zero`
+  (`diary.rs`).
 - [ ] `auto_header` — auto H1-from-filename on new page (server-side).
 - [ ] `create_link` — toggle to suppress link-target creation.
 - [ ] `dir_link` — index file to open when following a directory link.
@@ -521,6 +541,16 @@ audits don't re-flag them.
   → `diary` vs upstream `diary/` (trailing slash only — paths are joined
   identically, so behaviour matches). Listed so future audits stop re-flagging
   them; users can still set any of these explicitly.
+- **Generated-content syntax is vimwiki-only (for now)** _(noted 2026-06-02
+  re-audit)_ — the buffer-side generators (TOC, generated links, tags index,
+  diary index) always emit vimwiki markup (`= H =` headings via `caption_line`),
+  regardless of the wiki's `syntax`. Consequently the markdown-specific
+  `markdown_header_style` (blank lines after a generated *markdown* header) has
+  nothing to attach to and is deferred. This is a deliberate scoping choice, not
+  an oversight: markdown generated-content (markdown-style headings, then
+  `markdown_header_style`, `markdown_link_ext` in generated links) is planned as
+  a single later effort. Until then, markdown wikis get vimwiki-syntax generated
+  sections.
 
 ---
 
@@ -558,3 +588,10 @@ audits don't re-flag them.
   default output-location derivations (`path_html`/`template_path`/
   `diary_rel_path`) recorded as intentional divergences. No previously-closed
   item regressed.
+- Fixed the fourth-pass findings (2026-06-02), in order: `VimwikiRemoveDone`
+  `-range`; `list_margin` reworked to upstream's buffer-side meaning (HTML
+  `em`-margin dropped) + markdown-`0` default; `diary_months`;
+  `diary_caption_level` widened to `i8`. `markdown_header_style` deferred as part
+  of the documented "generated-content is vimwiki-only" divergence. All five
+  P1-blocking sections remain clear; only niche P3 items (and the deferred
+  markdown work) are left.