3865b8bf0e441713ecb59f6d2220361fa79c990a
174 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 gffranco
|
3865b8bf0e |
fix(parity): fifth-pass re-audit — VimwikiGoto nargs, autowriteall, table_auto_fmt
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> |
||
|
gffranco
|
c161f9d21a |
feat(parity): P3 quick-wins — ShowVersion, gLH/gLL/gLR, Search/Align nargs
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>
|
||
|
gffranco
|
9441fe918c |
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>
|
||
|
gffranco
|
079e7246ac |
fix(lists): VimwikiToggleRejectedListItem -range parity (P3)
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> |
||
|
gffranco
|
d8d1e9e39e |
docs(gap): check off html_header_numbering
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
79b502fa5c |
feat(html): html_header_numbering section numbering for HTML export
Mirror vimwiki's html_header_numbering / html_header_numbering_sym: top-level headings at or below the start level get a dotted section number (1, 1.1, 1.2, ...) with a configurable trailing symbol. Off by default (level 0). Nested headings in lists/quotes stay unnumbered, matching upstream's document-level-only scan. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
88114a65a4 |
test: land the vim diary -count cases + dedup the lua one (follow-up to 2da2168)
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>
|
||
|
gffranco
|
2da2168d88 |
fix(diary): complete the -count wiki selector (repair 874bdd0)
|
||
|
gffranco
|
874bdd0c02 |
feat(diary): -count wiki selector for diary-note + index commands (P3)
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>
|
||
|
gffranco
|
f0c07f0c28 |
feat(commands): ChangeSymbolTo -range, GenerateLinks path filter, NuwikiGenerateTags
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>
|
||
|
gffranco
|
f616915581 |
feat(commands): ChangeSymbolTo -range, GenerateLinks path filter, NuwikiGenerateTags
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>
|
||
|
gffranco
|
773bbdb6a6 |
docs(gap): record re-audit findings (3 new command gaps + 3 refinements)
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> |
||
|
gffranco
|
23f5a74086 |
test: add the Neovim *Link wrap cases referenced by 2b3bc48
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> |
||
|
gffranco
|
2b3bc48b75 |
fix(commands): route Neovim *Link Ex-commands through follow_link_or_create
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> |
||
|
gffranco
|
3b3d8ca782 |
feat(commands): command-line completion for Goto/Colorize/tag commands (P3)
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>
|
||
|
gffranco
|
efea225240 |
fix(commands): VimwikiTable default 5 cols (parity) + map audit findings
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> |
||
|
gffranco
|
acaaf107b4 |
feat(commands): VimwikiSplitLink/VSplitLink -nargs=* signature parity (P3)
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> |
||
|
gffranco
|
4710ba03c8 |
feat(commands): VimwikiListChangeLvl -range -nargs=+ (P3 parity)
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> |
||
|
gffranco
|
fe116088bb |
chore: untrack .claude/ session artifact, add to .gitignore
`git add -A` in the previous commit accidentally swept in .claude/scheduled_tasks.lock — a Claude Code local runtime artifact. Remove it from the index and gitignore the .claude/ dir so it can't recur. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
a7f7e8e61f |
feat(commands): VimwikiTable -nargs=* + Index/TabIndex -count=0 (P3 parity)
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> |
||
|
gffranco
|
724c12ac16 |
style: rustfmt the custom_wiki2html test assert (fixes red CI)
The custom_wiki2html test added in
|
||
|
gffranco
|
8dc4050b76 |
fix(commands)+docs: even out :NuwikiUISelect; exhaustive subgroup key lists
- ftplugin/vimwiki.vim: add buffer-local :NuwikiUISelect to the Vim path (it previously existed only on the Neovim path, contradicting the docs' "buffer-local on every .wiki buffer" claim — a global fallback masked it). Now symmetric with :VimwikiUISelect. - Make every keymap subgroup description list all of its bindings instead of trailing with "…": the README mappings-subgroups table, the README config-example comments, the README g:nuwiki_no_<group>_mappings rows, the doc/nuwiki.txt group→keys list, and the lua/nuwiki/config.lua comment. Also fixes the doc list that had dropped aH/iH from text_objects and adds the mouse group. Each notes that the <Leader>w prefix follows map_prefix. helptags validates (no dup tags); all keymap suites pass (266+18+21 Vim, 275 Lua); :NuwikiUISelect confirmed defined on a Vim .wiki buffer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
3e82f59f12 |
docs: fix stale README + help file (audit)
A three-agent audit cross-checked README.md and doc/nuwiki.txt against the actual config, commands, and mappings in code. Fixes: Mappings: - doc/nuwiki.txt wrongly described <Leader>ww as "open today's diary" — it opens the wiki index (diary-today is <Leader>w<Leader>w). Corrected, and the missing <Leader>wt (wiki index in a tab) row added. - README feature bullet referenced <Leader>ww for the diary; fixed to <Leader>w<Leader>w. - Both keymap listings now note <Leader>w is the default map_prefix. Config globals: - README globals table was missing real, code-read globals: g:nuwiki_syntax, g:nuwiki_diary_rel_path, g:nuwiki_wikis, g:nuwiki_map_prefix, g:nuwiki_binary_path, g:nuwiki_build_from_source. Added. - doc/nuwiki.txt globals section gained g:nuwiki_diary_rel_path and g:nuwiki_link_severity (both read in autoload but undocumented). - doc/nuwiki.txt per-wiki list gained template_date_format, html_filename_parameterization, color_dic, list_margin (in README only). Commands: - doc/nuwiki.txt was missing a whole list/task/table command group plus :NuwikiFindOrphans, :NuwikiNormalizeLink, :NuwikiColorize, :NuwikiPasteLink/PasteUrl/CatUrl. Added, matching README's descriptions. No default-value mismatches and no phantom (documented-but-nonexistent) entries were found. helptags validates with no duplicate tags. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
2a8e2b9ea9 |
fix(keymaps): correct Neovim global diary tab/tomorrow maps (map_prefix audit)
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> |
||
|
gffranco
|
feedd30c4d |
feat(keymaps): configurable map_prefix for the wiki command family (P2)
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>
|
||
|
gffranco
|
23aec3e6c7 |
feat(config): custom_wiki2html external converter + base_url for RSS (P2)
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> |
||
|
gffranco
|
09b5a2bd46 |
feat(config): on-save autoregen family — links/tags/diary-index (P2)
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> |
||
|
gffranco
|
3fd04b0efa |
fix(lsp): section-range termination is level-aware (caption audit follow-up)
The post-captions audit found find_section_range terminated a generated section only at the next *level-1* heading. With a custom non-1 *_header_level (e.g. a level-2 Generated Tags index) a following same-level section could be absorbed into the replaced span. Terminate at the next heading of level <= the matched section's level instead, which keeps the deeper `level+1` sub-groups inside while stopping at a sibling/parent. Test: find_section_range_stops_at_same_level_sibling. 0 failures, clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
545367c3f6 |
feat(config): configurable generated-section captions (P2)
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> |
||
|
gffranco
|
2d3db458fb |
feat(config): make listsym_rejected configurable (P2)
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> |
||
|
gffranco
|
624bccbe50 |
fix(client): honor count on Neovim Index; log third re-audit findings
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> |
||
|
gffranco
|
db9c1c5c11 |
feat: real range/bang/visual handling for the deferred command gaps
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>
|
||
|
gffranco
|
212b300fb4 |
fix(client): small mapping/command-attribute parity gaps
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>
|
||
|
gffranco
|
b8586537f8 |
feat(diary): restore diary_start_week_day via configurable weekly naming
|
||
|
gffranco
|
28d5caf581 |
fix(diary): default diary_caption_level to 0 (upstream parity)
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> |
||
|
gffranco
|
d8565fbe67 |
docs(gap): re-audit — confirm recent fixes, log new gaps
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> |
||
|
gffranco
|
086455e19b |
fix(client): P2 diary tab collision + <M-CR> badd-link parity
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
|
9de8543385 |
fix(client): colour-span conceal must skip unallocatable colours
A literal `<span style="color:…">` in prose (the sample wiki's own colorize instructions used one, with a `…` ellipsis as the colour) was matched by the scanner and fed to `highlight guifg=…`, which raised E254 on the un-silenced guifg line. That aborted the whole nuwiki#colors#refresh(), so on the Vim clients NO spans got concealed (start-vim) and follow-link crashed mid FileType autocmd (start-vim-coc). Neovim happened to dodge it depending on which buffer was scanned. s:define() now: - validates the colour (only #hex or an alphabetic name) and skips anything else — rgb()/hsl() functions and prose examples no longer create bogus conceal regions or errors; - runs both `highlight` calls under `silent!`, so a valid-format but unknown name can't abort the refresh either (tags still conceal, text just isn't recoloured). Also reworded the sample wiki's colorize note so it no longer embeds a literal span tag. Test: colorize.skips_unallocatable_colour (vim) — an rgb() span before a real one: refresh doesn't error, the rgb span isn't concealed, the real span still is. nvim 269, vim 260+18, all green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
15ba774a28 |
feat(client): conceal colour spans down to their coloured text
A :VimwikiColorize'd word showed the literal `<span style="color:NAME">TEXT</span>` markup. Now the tags are concealed and TEXT is painted in NAME, so the buffer shows just the coloured word — matching the HTML export. New autoload/nuwiki/colors.vim: nuwiki#colors#refresh() scans the buffer and, per distinct colour, defines a syntax region that conceals the `<span …>` / `</span>` tags (concealends) and highlights the body with the span's actual colour (guifg always; ctermfg for named colours). Idempotent (clears the group before redefining) and tracked in b:nuwiki_color_seen. Refresh is driven from three places so it's both correct and immediate: - syntax/vimwiki.vim: initial pass + re-establish after :colorscheme reload (resets the per-buffer cache since :syntax clear drops the regions); - ftplugin TextChanged/InsertLeave autocmd for spans that arrive via paste/ undo/external edits; - colorize() itself calls refresh() right after wrapping, so a freshly colorized word conceals instantly (TextChanged doesn't fire reliably mid command / in headless ex-mode). The LSP @vimwikiColor token no longer links to Constant, so in Neovim it doesn't override the real per-span colour on the concealed text. Pure syntax + :highlight — works identically in Vim, coc.nvim, and Neovim, no LSP needed. Tests: colorize.conceal_hides_tags_shows_text (both harnesses) and colorize.command_conceals_immediately (vim). Sample wiki's colorize section notes the conceal. nvim 269, vim 259+18, config-parity green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
2facb40265 |
fix(client): VimwikiColorize accepts a range (no more E481 on selection)
Selecting text and running :VimwikiColorize {color} raised
"E481: No range allowed" — Vim prepends '<,'> to the command when invoked
from a visual selection, but the command was defined without -range.
All four colorize command defs (Vim + Neovim, Vimwiki* + Nuwiki*) are now
-range and forward the range count to the handler. A ranged (visual)
invocation wraps the '< / '> selection; a bare invocation wraps the cword.
The x-mode <Leader>wc mapping passes the visual flag explicitly.
The Vim-branch colorize() gained selection support (it was cword-only),
matching the Neovim branch, so both clients wrap a visual selection
identically. visual_selection_range() (Lua) no longer gates on
vim.fn.visualmode() — the explicit visual flag now carries that intent, and
the marks check guards unset selections.
Tests: cmd.Colorize_range_wraps_selection (nvim) and
colorize.{command_wraps_cword,visual_wraps_selection,ranged_command_no_error}
(vim). nvim 268, vim 257+18, all green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
gffranco
|
279dacff7a |
dev: add a colorize section to the scratch sample wiki
The sample wiki had no place to exercise :VimwikiColorize. Add a "Colour spans" section to Syntax.wiki with words/phrases to wrap (and an already- colorized span to render), plus a pointer in index.wiki's "Commands to try" list. Lets the start-* launchers smoke-test the colorize fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
66bfd61a63 |
fix(client): VimwikiColorize passes its {color} arg on Neovim + visual fix
The Neovim command defs for :VimwikiColorize / :NuwikiColorize were -nargs=1 but called colorize() without <q-args>, so the colour name was silently dropped and the user was prompted instead (the Vim branch passed it correctly). Pass <q-args>. While verifying, found a second bug in the Lua colorize(): it inferred visual-vs-normal from vim.fn.visualmode(), which returns the *last* visual mode used in the session along with stale '< / '> marks. So running :VimwikiColorize in normal mode after any earlier visual selection wrapped that leftover selection instead of the word under the cursor (produced an empty, misplaced span). colorize(color, visual) now takes an explicit visual flag, passed only by the x-mode <Leader>wc mapping; the command and the normal-mode mapping always wrap the cword. Tests: cmd.VimwikiColorize_uses_arg, cmd.NuwikiColorize_uses_arg, cmd.Colorize_ignores_stale_visual_selection, colorize.visual_wraps_selection in test-keymaps.lua. nvim suite 267, vim suite 254+18, all green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
39692ba99f |
dev: start-* launchers always start from a clean setup
The launchers reused whatever was left under $XDG_CACHE_HOME/nuwiki-dev between runs — seed_wiki() skipped reseeding when index.wiki already existed, so stale edits from a previous session leaked into the next, and old swap/viminfo/coc state carried over. Each launch now starts clean: - seed_wiki() reseeds the managed scratch wiki from a pristine copy every run (rm -rf + write_sample_wiki). A user-pointed NUWIKI_DEV_WIKI is never wiped — it's seeded only when empty, so a real wiki is never clobbered. NUWIKI_DEV_NO_SEED still bypasses seeding entirely. - new reset_dirs() helper wipes + recreates each launcher's owned state dirs (vim viminfo/swap/undo, coc data, nvim XDG state/data/config) before launch. Cached plugin clones (vim-lsp, async.vim, coc.nvim) are kept — only the wiki and editor state are reset. Header docs updated to describe the fresh-each-launch behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
6983daa637 |
fix(follow-link): resolve+open definitions ourselves on the Vim clients
The Vim follow-link path delegated to the LSP client's jump UI
(:LspDefinition / coc jumpDefinition), which broke two ways for wiki
link-following:
1. **No create-on-follow (vim-lsp + coc).** vim-lsp's location handler
readfile()s the target to build a quickfix entry; for a not-yet-created
page that throws E484 and aborts the jump, so <CR> on [[NewPage]] did
nothing. The server was correct throughout — textDocument/definition
returns a *synthesised* location for missing pages (verified over
JSON-RPC).
2. **Wrong window placement (coc).** Without an explicit open command coc
fell back to coc.preferences.jumpCommand (e.g. a tab command).
Stop delegating: nuwiki#commands#follow_link_or_create() /
follow_link_drop() now resolve textDocument/definition directly and open
the URI themselves via a shared s:open_definition(open_cmd) helper — :edit
for <CR>, `tab drop` for <C-S-CR>. :edit opens a buffer for a missing path
(save creates it, matching vimwiki) and gives exact current-window
placement regardless of the user's coc jumpCommand. Removes
s:jump_definition / s:drop_from_response.
Also fix the coc action name: CocAction('getDefinition') does not exist
(E605 "Action getDefinition does not exist") — the registered action is
'definitions'. Fixed in s:open_definition and badd_link.
coc config delivery: the setup guidance shipped without
initializationOptions, so coc users never sent wiki_root and the server
resolved links against its default root (existing pages flagged broken,
follow-to-create landed in the cwd). The printed snippet
(autoload/nuwiki/lsp.vim) now emits initializationOptions populated with
the resolved settings, and the README coc snippet documents it as required.
Add development/start-vim-coc.sh — a coc.nvim dev launcher (sibling of
start-vim.sh) that wires coc's prebuilt release branch + a generated
coc-settings.json (with initializationOptions), deliberately omitting
vim-lsp so the coc path is exercised; doubles as a reproducer.
Tests: new cr.follow_opens_missing_page_in_current_window case in
test-keymaps-vim.vim (stubs CocAction to a missing page, asserts
current-window :edit). Keymap suite 254+18 green; config-parity (Vim +
Neovim) green. Neovim path unchanged and re-confirmed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
gffranco
|
52848a0663 | addin spec for calendar integration | ||
|
gffranco
|
45e2d1769a |
docs(keymaps): correct lists group comment to gl/gL
The lists mapping comment still listed gl<Space>; bare gl/gL are now the remove-checkbox maps after the P1 #3 parity change. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
gffranco
|
ac4dd144e4 |
docs(gap): expand audit findings
Reframe diary_start_week_day as a wrongly-removed client-side concern that matters for parity (non-Monday users lose the upstream option). Add four P3 command-divergence rows (Neovim VimwikiColorize arg-drop, TableMoveColumn backing-name split, NuwikiTabIndex missing -count, ToggleListItem/Increment/Decrement missing -range) and a P3 mappings row for the gLH/gLL/gLR case-variant aliases. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
gffranco
|
c5814a3e21 |
docs(gap): log <CR> link-follow new-tab regression
Pressing <CR> on a link now opens a new tab and switches to it instead of reusing the current window (reported on Vim 9.x + Dein). Records the investigation so far — the <CR> path is unchanged by recent P1 work and both client jump paths open same-window by default — and the env gotchas (stale dein copy, double rtp) to rule out before treating it as a code bug. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
gffranco
|
1521d6c096 |
docs(client): document bare gl/gL remove-checkbox + tick parity gap P1 #3
Update the lists keymap tables and group hints (gl/gL = remove checkbox; remove-done is command-only via :NuwikiRemoveDone[!]), note the 'timeoutlen' prefix behavior, and tick P1 #3 in the vimwiki gap tracker. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
gffranco
|
cca2043294 |
test(client): cover bare gl/gL remove-checkbox + command-driven remove-done
Swap the gl<Space>/gL<Space> surface assertions for bare gl/gL; add behavioral cases for gl (item) and gL (whole list) remove-checkbox, and drive remove-done through :NuwikiRemoveDone / :NuwikiRemoveDone! now that it is command-only. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |