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>
`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>
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>
The custom_wiki2html test added in 23aec3e had an over-width `assert!`
that `cargo fmt` wants wrapped; CI's `cargo fmt --all -- --check` job has
been failing on it since. No behavior change — `cargo fmt --all` only.
Verified locally against the exact CI matrix: fmt --check clean, clippy
--workspace --all-targets -D warnings clean, test --workspace --all-targets
all pass, keymap + config harnesses pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Upstream vimwiki binds bare gl/gL to remove-checkbox (item / whole list);
nuwiki had rebound the conceptual keys to gl<Space>/gL<Space> as remove-done,
a same-keys-different-effect parity trap. Bind bare gl/gL to remove-checkbox
instead — they share the gl… prefix so they fire after 'timeoutlen', exactly
as upstream. Remove-done becomes command-only; add -bang to *RemoveDone so
:NuwikiRemoveDone! reaches the whole-buffer sweep that gL<Space> previously
held (its only entry point).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adding list_margin pushed render_page_html to 8 params, tripping
clippy::too_many_arguments under -D warnings in CI. Every parameter is a
distinct render input and the function has a single production caller, so
scope an #[allow] rather than introduce an options-struct abstraction.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add gl<sym>/gL<sym> to the lists keymap tables in README and help, noting
that 1) is command-only. Tick parity gap P1 #2.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Upstream's one-key marker-change keys had no nuwiki binding — the
functionality was reachable only via :NuwikiChangeSymbol. Add normal-mode
gl{-,*,#,1,i,I,a,A} (current item) and gL{...} (whole list) to both
clients, wired to the existing list_change_symbol command. NumericParen
1) stays command-only, matching upstream's default number_types shadowing.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The split/tab link-follow commands are no longer Neovim-only; document
:Nuwiki/Vimwiki{Split,VSplit,Tabnew,TabDrop,GoBack}Link and note that
<C-S-CR> follows a link in a tab reusing an existing one. Tick parity
gap P1 #1 in the tracking doc.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add SplitLink/VSplitLink/TabnewLink/TabDropLink/GoBackLink to both
keymap harness command lists, plus a smoke check that
nuwiki.commands.follow_link_drop is callable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The plain-Vim client only defined VimwikiFollowLink; the split/vsplit/
tabnew/tabdrop/back command surface existed only in the Neovim branch.
Add :Vimwiki{Split,VSplit,Tabnew,TabDrop,GoBack}Link (+ :Nuwiki* aliases)
to the Vim branch, backed by a new nuwiki#commands#follow_link_drop()
helper that runs `:tab drop` to reuse an already-open tab.
Both clients now implement real tab-drop: open_uri gains a 'tabdrop'
case and M.follow_link_drop(); the Neovim TabDropLink commands and the
<C-S-CR> mappings (Vim + Lua) are repointed off the old tabnew cheat.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add development/vimwiki-gap.md, a checkbox-tracked audit of where nuwiki
diverges from upstream vimwiki across configuration options, Ex-commands,
and key mappings. Items are prioritised P1–P3 with a fix site cited on
each, plus an "intentional divergences" section so the LSP-rearchitected
choices aren't re-flagged in future audits.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The plain-Vim ftplugin only exposed a whole-layer
g:nuwiki_no_default_mappings gate, so Vim users could not drop a single
keymap group the way Neovim users can via mappings.<group> = false. Add
g:nuwiki_no_{wiki_prefix,links,lists,headers,table_editing,diary,
html_export,text_objects}_mappings, each wrapping its group block, to
reach parity with lua/nuwiki/keymaps.lua. Cover them with a dedicated
opt-out harness and document them in the README and help file.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Parse editor and export documents with each wiki's configured listsyms,
and make toggle/cycle/reject plus parent-propagation walk the real
palette glyphs instead of the hardcoded ' .oOX'. Falls back to the
default palette when no wiki matches the URI.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add a ListSyms type (vimwiki's g:vimwiki_listsyms) and thread it through
the lexer so checkbox glyphs are recognized from the configured palette
rather than the hardcoded ' .oOX'. Glyphs map to the existing five-bucket
CheckboxState, so the HTML renderer and AST consumers are unchanged.
VimwikiSyntax::parse_with_listsyms opts into a custom palette; the trait
parse() keeps the default.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Remove nested_syntaxes, maxhi and diary_start_week_day from the config
reference (block, tables and key lists) since the server no longer
consumes them, and note that language-tagged code fences are highlighted
automatically with no nested_syntaxes key.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Consume several per-wiki config keys that the server deserialized but
ignored, and remove keys whose effect is purely client-side:
- diagnostics: re-publish open-doc diagnostics on
didChangeConfiguration so a link_severity change takes effect
immediately; fix the single-key unwrap in apply_change so a minimal
`{ diagnostic: {...} }` payload isn't mistaken for a namespace wrapper.
- auto_toc: rebuild an existing TOC section on save (new
ops::toc_rebuild_edit, no-op when the page has no TOC).
- diary index: honour diary_header, diary_sort and diary_caption_level
when rendering the diary index body.
- links_space_char: apply on rename so spaces in the link target and
the on-disk path become the configured glyph (default " " = verbatim).
- list_margin: thread the per-wiki value into render_page_html.
- remove nested_syntaxes, maxhi and diary_start_week_day from the server
config: nested-syntax and heading highlighting are client-side, and
the weekly diary is ISO-week based so a custom week start has no clean
server-side meaning.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add `HtmlRenderer::with_list_margin`. When the margin is >= 0 the
outermost list gets an inline `margin-left:<n>em`; nested lists and the
default of -1 stay unstyled (deferring to the stylesheet). Wires the
per-wiki vimwiki `list_margin` key into the export pipeline.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
gffranco