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 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 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>
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>
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>
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 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>
gffranco