4c187fee3c52ecee30219769e2c9b544a896584d
85 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 gffranco
|
4c187fee3c |
fix(tables): don't split a cell on a | inside a link/code/escape
CI / editor tests (push) Successful in 46s
Table auto-alignment scanned for cell separators with a naive find('|'),
so a cell containing a vimwiki link `[[url|title]]` was split at the link's
internal pipe — mangling both the link (`[[url` / `title]]`) and the table
(a phantom extra column). Same bug in both the Lua (Neovim) and VimL (Vim)
table code, in both table_cell_starts and parse_table_row.
Add a shared cell-separator scanner (cell_bar_positions) that treats `|` as
literal — not a separator — when it's inside `[[…]]` wikilinks, `{{…}}`
transclusions, `` `…` `` inline code, or backslash-escaped (`\|`), matching
vimwiki. Both scan functions in each client now use it.
Regression tests added on both clients (cr.table_link_cell_pipe_not_a_separator);
full harness green (Neovim 308, Vim 302).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
gffranco
|
4bee216c05 |
refactor(client): self-review cleanup — dead code, dedup, parity, stale comments
CI / editor tests (push) Successful in 45s
A code-review pass over the VimL + Lua client layers (no behaviour change
beyond the noted parity fixes; full editor harness 10/10):
Lua (lua/nuwiki/):
- commands.lua: drop the dead <0.10 make_position_params pcall/no-arg fallback
(min is 0.11; no-arg form is itself deprecated) and its stale comment.
- commands.lua: simplify the exec() client dispatch — the metatable/rawget
dance is gone; always use the non-deprecated colon form client:request() on
0.11+. (This is the block an external review misread as "critical".)
- commands.lua: extract parse_list_marker() + has_auto_indent() shared by
smart_return/smart_shift_return; extract word_boundaries() shared by
wrap_cword_as_wikilink/colorize (and unify the equivalent char classes).
- commands.lua: :Nuwiki search now surfaces real lvimgrep errors instead of
reporting every failure as "no match" (E480 stays a WARN) — parity with the
VimL twin's `catch /E480/`.
- keymaps.lua: collapse open_below/above_with_bullet into open_with_bullet(cmd)
(checkbox prefix preserved for `o` only, as before).
- lsp.lua: normalize the wiki root before the buffer-path prefix compare
(Windows separators); buf path was already normalized.
- ftplugin.lua: drop the always-true has('nvim-0.11') guard and hoist the
identical foldmethod/foldtext out of both branches.
- install.lua: use a local `uv` instead of mutating the global vim.uv.
VimL (autoload/nuwiki/):
- commands.vim: refresh a stale comment pointing at the old in-repo
nuwiki-lsp/src/commands.rs path → the nuwiki-rs server generally.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
gffranco
|
a9208db2e4 |
fix(lua): recognize spaceless headings (==Heading==) in client helpers
CI / editor tests (push) Successful in 44s
The shared heading_level helper still required spaces around the title, so the client-side regex paths — fold fallback, text objects (ah/ih), and heading navigation (]] etc.) — skipped spaceless headings, even though the server (and HTML export) accept them since the #7 fix. Rewrite to match the lexer: balanced leading/trailing `=` runs (cap 6) around a non-empty title, spaced or spaceless. Marker-only (`======`), unbalanced (`==a==b`, `==> x`) and 7+ runs still return 0. Verified against an 18-case battery + full editor harness (10/10). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
ac1db1af1d |
refactor(lua): extract shared heading_level/is_table_row; dedup wiki_list in search
CI / editor tests (push) Successful in 48s
Pulls the duplicated heading_level (keymaps/folding/textobjects) and is_table_row (commands/textobjects) helpers into lua/nuwiki/util.lua. The copies had drifted — only folding capped level >6 and only commands nil-guarded is_table_row; the unified versions keep both (cap + nil-safe), which also aligns the keymap/textobject paths with the server's level cap. search() now resolves config.wiki_list() once instead of twice. No behaviour change beyond the >6 cap now applying everywhere. Full editor harness green (10/10). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
 gffranco
|
cb11889e72 |
Remove Rust code, delegate server to nuwiki-rs repo
Delete all Rust crates (crates/) and Cargo files. The nuwiki-ls binary is now built in the separate nuwiki-rs repository and downloaded at install time from the Gitea release assets, with a cargo build fallback that clones nuwiki-rs. Update all documentation to reflect the split repo layout. |
||
|
gffranco
|
0d1a73a3ba |
feat(config): bridge setup({wikis}) to g:nuwiki_wikis for VimL plugins
A Lua-only `setup({ wikis = … })` config is invisible to the VimL side:
the buffer helpers in autoload/nuwiki/config.vim and the vimwiki compat
shim (autoload/vimwiki/vars.vim, which third-party plugins like
vimwiki-sync call via vimwiki#vars#get_wikilocal) read g:nuwiki_wikis. So
a Neovim user who migrated from g:vimwiki_list to native setup({wikis})
would break vimwiki-sync (it'd resolve the default ~/vimwiki).
setup() now publishes the resolved wiki list to g:nuwiki_wikis when the
config came from setup() opts (the only case VimL can't already see —
g:nuwiki_wikis / g:vimwiki_list configs are global and visible). Verified
vimwiki#vars#get_wikilocal('path', n) returns the right roots from a
pure-Lua setup() config. test-global-shorthand grows two bridge checks
(17). Goldens + keymap harnesses green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
gffranco
|
e6f400b370 |
feat(config): read g:vimwiki_list on Neovim too (lazy.nvim drop-in)
The g:vimwiki_* drop-in was Vim-only: the Lua client read only setup() opts and g:nuwiki_wikis, so swapping the vimwiki plugin for nuwiki under lazy.nvim left the existing vim.g.vimwiki_list ignored and nuwiki pointed at the default ~/vimwiki. Mirror autoload/nuwiki/config.vim on the Lua side: config.lua now owns a single resolver (M.wikis / M.scalar_globals) that resolves setup() wikis → g:nuwiki_wikis → g:vimwiki_list (translating path->root, path_html->html_path, template_*, ext->file_extension, …) and folds the global scalar defaults (g:vimwiki_* then g:nuwiki_* then explicit setup() values; built-in defaults excluded). lsp.lua (payload) and wiki_cfg/wiki_list (buffer commands) both route through it, so the server and <Leader>ww agree on the wikis. Extends test-global-shorthand (15 checks) with the vimwiki_list drop-in + buffer-command resolution + native-wins cases. Config-parity goldens and keymap harnesses green on both clients. README + known-issues updated (drop-in is now Vim & Neovim). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
c144cbbb55 |
fix(install): simplify to the direct /releases/download/latest/ URL
Gitea serves the most recent release under the `latest` tag segment, so `/releases/download/latest/nuwiki-ls-<target>.tar.gz` resolves directly (HTTP 200) — no API lookup or JSON parsing needed. Drop the latest_asset_url helpers added in the previous fix; the only real bug was the URL shape (`/releases/latest/download/` is GitHub-only and 404s on Gitea). Both install paths now just pick the target and build the URL. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
3c1ed48a2f |
fix(install): resolve release asset via Gitea API (download was always 404)
:NuwikiInstall always fell back to building from source because the download URL used the GitHub-only shape `/releases/latest/download/<asset>`, which this Gitea instance serves as 404. The release assets exist and are correctly named; only the URL was wrong. Resolve the asset's real download URL through the Gitea API instead: GET `/api/v1/repos/.../releases/latest`, find the asset matching `nuwiki-ls-<target>.tar.gz`, and download its `browser_download_url` (`/releases/download/<tag>/<asset>`, which returns 200). Fixed in both install paths — lua/nuwiki/install.lua (vim.json.decode) and scripts/download_bin.vim (json_decode). Verified end to end: resolve → download → extract → executable binary. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
f0c51fbfcc |
feat(generate): insert links/tags sections at the cursor line too
Extend the cursor-line insertion from :NuwikiTOC to the other buffer list generators: :NuwikiGenerateLinks and :NuwikiGenerateTagLinks. They appended at end-of-file; a fresh section now goes at the cursor line (with a leading blank), matching :NuwikiTOC. An existing section is still refreshed in place, and the auto_generate_*-on-save hooks are unaffected (they only ever replace). Shared section_insert() helper computes the insert position/block for all three (cursor line clamped to the document, else the per-command fallback: top of file for TOC, EOF for links/tags). Clients send the 0-based cursor line; handlers parse it via parse_uri_line_arg and thread it through links_edit / tag_links_edit. Rebuild variants pass None. Tests: links_edit_inserts_at_cursor_line + tag_links_edit_inserts_at_cursor_line. 577 passed, clippy clean, keymap harnesses green. Docs updated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
94cb58064d |
feat(toc): insert a fresh TOC at the cursor line
:NuwikiTOC inserted a new table of contents at the top of the file. It now inserts at the cursor line instead, so you can place the TOC where you want it (a blank line separates it from preceding text). An existing TOC is still refreshed in place, and auto_toc-on-save is unaffected. The Vim/Lua clients send the 0-based cursor line with nuwiki.toc.generate; the server threads it into toc_edit (clamped to the document) and falls back to the top of the file when absent. toc_rebuild_edit passes None. Tests: toc_edit_inserts_at_cursor_line + toc_edit_cursor_line_clamped_and_existing_replaced_in_place. 575 passed, clippy clean, keymap harnesses green. Doc updated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
9d89e01ed8 |
feat(config): vimwiki drop-in config + global per-wiki defaults
Two related config-ergonomics features for vimwiki migrants, sharing the
same scalar-global machinery.
1. Upstream g:vimwiki_* drop-in (Vim client). When nuwiki isn't configured
natively, the Vim client reads g:vimwiki_list + g:vimwiki_* globals and
translates them into nuwiki's schema: per-wiki path->root,
path_html->html_path, template_*, css_name, auto_export/auto_toc,
syntax, ext->file_extension, index, diary_*, name. g:nuwiki_* always
wins. Lets a vimwiki user drop in nuwiki without rewriting config.
2. Global per-wiki defaults (both clients). A display/generation setting
given once at the top level — g:nuwiki_<key> / setup({<key>=…}) /
g:vimwiki_<key> — is folded into every wiki as a default; a per-wiki
value overrides it (vimwiki's model). Covers toc_header(_level),
toc_link_format, links_header(_level), tags_header(_level),
html_header_numbering(_sym), links_space_char, list_margin, listsyms,
listsym_rejected, and the auto_* toggles. Only values the user
explicitly set fold — built-in defaults don't (added config.user
tracking on the Lua side so a default toc_header_level=1 isn't pushed
onto every wiki). User config tables are never mutated.
Both clients kept in lock-step (config-parity golden enforces identical
payloads). New harnesses test-vimwiki-compat-vim (18) and
test-global-shorthand (8), wired into CI. Server test
vimwiki_compat_payload_sets_toc_level_per_wiki. Docs in README +
known-issues.md (drop-in is currently Vim-only). Rust 573 passed, clippy
clean, all harnesses green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
gffranco
|
f3d8af5f23 |
fix: TOC header class, numbering config, and Lua defaults
CI / cargo fmt --check (push) Successful in 31s
CI / cargo clippy (push) Successful in 31s
CI / cargo test (push) Successful in 36s
Release / build x86_64-unknown-linux-gnu (push) Successful in 53s
Release / build aarch64-unknown-linux-musl (push) Successful in 1m6s
Release / build x86_64-unknown-linux-musl (push) Successful in 1m8s
Release / build aarch64-unknown-linux-gnu (push) Successful in 1m47s
Release / gitea release (push) Successful in 28s
CI / editor keymaps (push) Successful in 1m39s
- Add class='toc' to TOC heading in HTML export by detecting the configured toc_header value in render_heading() - Add toc_header field to HtmlRenderer and wire it through render_page_html() - Add toc_header, toc_header_level, html_header_numbering, and html_header_numbering_sym to Lua config defaults so users can discover and set them |
||
|
gffranco
|
3b92b11948 |
fix(review): close all 2026-06-03 codebase-review findings (R1-R18)
Resolves the 18 findings from the parallel codebase review, tracked in development/vimwiki-gap.md. Correctness / perf: - Wiki.config -> Arc<WikiConfig> so cloning a Wiki is a refcount bump (R5) - WorkspaceIndex::remove is no longer O(n^2): a per-source contributions map limits the scan to buckets the source actually wrote into (R6) - render_color now expands color_tag_template (__STYLE__/__CONTENT__), consuming the previously-dead field; ColorNode documented as an extension point; 3 renderer tests added (R3/R4) - wiki_root_for returns empty/nil on no-match instead of falling back to the first wiki (R2); auto_header honours links_space_char (R7) Cleanup / dedup: - Remove dead #[allow(dead_code)] stubs + uncalled pub helpers, narrow imports (R10/R11) - Dedup span_of_inline x3 -> InlineNode::span() (R12) - diary_step single read lock; page_captions single pass (R13) - Lua auto_header loop -> wiki_list(); detect_current_symbol cleanup (R14/R18) Client / docs: - :VimwikiNormalizeLink Vim cmds -> <q-args> (R17); ftplugin header fix (R16); vars.vim multi-wiki limitation documented (R15) - Document 19 config options in README.md + doc/nuwiki.txt; fix list_margin/shiftwidth doc and stale comments (R1/R9) - R8 investigated, confirmed not a real bug (documented) Verified: Neovim harness 307, Vim harness 301/18/21, Rust suite 568, all 0 failed; clippy clean; fresh parallel-agent audit found no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
gffranco
|
1246c99c3c |
fix(config): address P3 config-batch audit findings
Parallel-agent audit of the config batch found: - cycle_bullets used find_marker_span's third element as an indent column, but it's the ABSOLUTE byte offset after the marker — so depth (and the rotated glyph) was wrong for any item not near offset 0 (tests passed by coincidence). Fixed to use the marker span's column (the indentation). Regression test now places the list deep in the document. - :VimwikiColorize interpolated the colour into the template via an unescaped replacement: Lua gsub treats `%` specially, Vim substitute() treats `&`/`\`. Lua now uses a function replacement (verbatim); Vim escapes `\&~`. - render_swapped_table applied table_reduce_last_col before the column swap, so a swap involving the last column moved the narrow slot — now clamped after. - Fixed a stale toc_link_format doc comment (format 1 = [[#anchor]], not a full parent path). Verified-correct by the audit (no change needed): RSS rfc822/cdata/fidelity, prune_orphan_html reverse-mapping + guards, write_escaped_allowing/match_allowed_tag (multibyte-safe), substitute_emoji (byte-boundary-safe), resolve_target_uri create_link/dir_link ordering, all config defaults + From/constructors. Full rust suite + clippy clean; Neovim 307, Vim 301/18/21. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
5d1ac09245 |
feat(config): P3 config batch — group 4 (valid_html_tags, emoji, color_tag_template)
- valid_html_tags: HTML export now passes the allowlisted inline tags through verbatim (b/i/sub/sup/kbd/div/center/strong/em/...) and escapes the rest, via a render-time tag-aware escaper (write_escaped_allowing/match_allowed_tag) — mirroring upstream's s:safe_html_line regex rather than a parser change. `span` is always allowed so colour spans render. - emoji_enable: render-time `:alias:` -> glyph substitution (curated common set), default on; with_emoji builder + substitute_emoji/emoji_for. - color_tag_template: :VimwikiColorize now wraps via a configurable template (g:nuwiki_color_tag_template / setup color_tag_template), splitting on __CONTENT__ with __COLORFG__ -> colour; both clients. Colour spans render in export via the valid_html_tags span passthrough. Default template reproduces the prior `<span style="color:NAME">` output (harness colorize tests green). Renderer gets with_valid_html_tags + with_emoji; export.rs wires both from HtmlConfig. Tests: valid_html_tags passthrough + escape, emoji on/off (html_export.rs). Full rust suite + both harnesses green (Neovim 307, Vim 301/18/21); clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
87d14310fc |
feat(config): P3 config batch — group 2 (create_link, dir_link, auto_header)
- create_link (default true): server resolve_target_uri now only synthesises a missing-page URI when create_link is set; when off, following a link to a non-existent page returns no location (no-op). - dir_link: a [[dir/]] link now resolves to <dir>/<dir_link><ext> when dir_link is set, else opens the directory itself. Uses the already-parsed LinkTarget.is_directory. - auto_header (default off): new wiki pages get a `= Stem =` header derived from the filename, skipping the wiki index + diary index. Client-side BufNewFile autocmd in both clients (init.lua + plugin/nuwiki.vim), with auto_header handlers in both command layers (trailing-slash-robust root matching). Tests: cmd.auto_header_inserts + cmd.auto_header_skips_diary_index (nvim) / cmd.auto_header_skips_index (vim). Full rust suite + both harnesses green (Neovim 307, Vim 301/18/21). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
b2f2fc88bd |
feat(config): P3 config batch — group 1 (clean config + plumbing)
Config plumbing for the whole config batch (HtmlConfig + WikiConfig fields, RawWiki deserialization, From/defaults) plus these behaviors: - rss_name / rss_max_items: HtmlConfig fields (wired into write_rss in the RSS group). - toc_link_format: build_toc_text emits [[#anchor]] (no description) for 1, [[#anchor|title]] for 0. - generated_links_caption: build_links_text emits [[page|FirstHeading]] from a page->heading map (ops::page_captions) when enabled. - table_reduce_last_col: column_widths clamps the last column to width 1 when set; threaded through table_align_edit/table_move_column_edit + commands. - color_dic now ships a populated default palette (red/green/blue/...). - commentstring aligned to upstream's no-space `%%%s`. - auto_chdir (default off): :lcd into the owning wiki root on buffer enter; both clients (ftplugin.lua setup_auto_chdir + Vim NuwikiAutoChdir augroup), with config.wiki_root_for / nuwiki#commands#wiki_root_for resolvers. Also seeded HtmlConfig fields for later groups (valid_html_tags, list/text_ignore_newline, emoji_enable, user_htmls, color_tag_template) and WikiConfig (create_link, dir_link, bullet_types, cycle_bullets). Tests: toc_link_format, generated_links_caption, table_reduce_last_col, config defaults + JSON round-trip for every new key. Full rust suite + both keymap harnesses green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
03005d0931 |
fix(insert): pumvisible() guard on smart_return/smart_shift_return (audit follow-up)
The mappings re-audit confirmed the two new bindings (visual <CR> normalize, insert <S-CR> multiline item) are correct — column math matches upstream's s:text_begin, auto-indent handling sound, no parity gaps or regressions. It flagged one low-severity item shared with the pre-existing smart_return: neither guarded the completion popup. Upstream maps <CR>/<S-CR> as `pumvisible() ? '<CR>' : …`. Added that guard to both smart_return and smart_shift_return (both clients) so a <CR>/<S-CR> accepts the completion instead of continuing the list when the popup is open. Left as a documented minor divergence: <S-CR> on an *empty* bullet emits the aligned no-marker continuation rather than upstream's "blank line above, keep marker" (niche). Neovim 305, Vim 299/18/21 pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
gffranco
|
724712121d |
feat(parity): close the entire P3 Mappings section
Both remaining mapping gaps (client-side, both clients):
- Visual <CR>: upstream binds it to NormalizeLinkVisualCR (== visual `+`).
Added `x <CR>` -> normalize_link(true) (wrap the selection as a wikilink)
in both clients.
- Insert <S-CR>: upstream's multiline-list-item continuation (VimwikiReturn
2 2 -> kbd_cr with no new marker). New smart_shift_return (both clients,
<expr> insert mapping): on a list item returns <CR> + spaces aligning under
the item text (marker width + 1, +4 for a `[ ] ` checkbox), no marker; off a
list item, a plain <CR>. Mirrors smart_return's auto-indent handling.
Tests: map.visual_cr_wraps_selection + map.insert_shift_cr_multiline
(test-keymaps.lua, the latter exercising the handler directly since <S-CR>
doesn't round-trip headless feedkeys), and map.visual_cr_wraps_selection +
cr.shift_cr_multiline{,_checkbox} (test-keymaps-vim.vim). Docs (README +
doc/nuwiki.txt) and the gap doc updated. Neovim 305, Vim 299/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
gffranco
|
305324c6e9 |
Merge remote-tracking branch 'origin/calendar-support' into feature-gap
# Conflicts: # development/vimwiki-gap.md |
||
|
gffranco
|
6deba47106 |
fix(search): graceful no-match + NuwikiSearch alias (re-audit follow-up)
Re-audit of the just-landed command work found one real bug I introduced
and a convention gap:
- VimwikiSearch / VWS raised a raw E480 on a no-match search; upstream
reports it gracefully. Both clients now catch it (try/catch in Vim,
pcall in Neovim) and emit "nuwiki: no match for <pat>".
- Added a NuwikiSearch alias alongside VimwikiSearch/VWS (every other
command carries a Nuwiki* form).
Gap-doc note corrected: nuwiki's search populates + opens the location
list (shows all matches) where upstream jumps to the first match — logged
as a minor presentation divergence rather than claiming exact parity.
Config + mappings re-audits came back clean (no new gaps, no regressions;
table-mapping rewire verified non-recursive, gLH/gLL/gLR present).
Tests: cmd.VimwikiSearch_no_match_graceful, surface.{Vimwiki,Nuwiki}Search.
Neovim 301, Vim 294/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
gffranco
|
a11b742fc1 |
feat(parity): close the entire P3 Commands section
All six remaining command gaps (client-side; no server change):
- VimwikiRenameFile: bare -> -nargs=? (arg accepted-ignored; rename still
delegates to the LSP rename prompt). No more E488.
- VimwikiVar / NuwikiVar: get/set the client config (upstream vimwiki#vars#cmd).
No arg prints config (Vim: g:nuwiki_*; Neovim: resolved setup() opts), one arg
gets a key, two+ sets it. Global command, both clients.
- VimwikiReturn / NuwikiReturn: command form of the smart <CR> continuation —
enters insert at EOL and fires the <CR> mapping (return_cmd / vimwiki_return).
Upstream's mode-flag args accepted but unused.
- VimwikiTableAlignQ vs AlignW: corrected — upstream's gqq/gww are identical on
a table; the only difference is the non-table fallback (native `normal! gqq`
vs `gww`). New table_align_or_cmd(cmd) aligns on a table row, else runs
`normal! <cmd>`. Q/gqq/gq1 -> gqq; W/gww/gw1 -> gww; NuwikiTableAlign -> gqq.
- VimwikiSearch / VWS: scope the lvimgrep to the current wiki's root (resolved
client-side) over <root>/**/*<ext>, not CWD `**`; empty pattern reuses the
last search. Both clients.
- VimwikiIndex family: add global Vimwiki/NuwikiIndex + TabIndex entry points
(plugin/nuwiki.vim + init.lua _setup_global_commands, with -count), so a wiki
opens from any buffer. Buffer-local copies still shadow inside wiki buffers.
Tests: surface.{Vimwiki,Nuwiki}{Return,Var}, cmd.VimwikiVar_sets_*,
cmd.global_entry_points (both harnesses). Docs (README + doc/nuwiki.txt) and the
gap doc updated. Neovim 299, Vim 291/18/21 pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
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
|
87ba4c1764 |
test(calendar): add Vim + Neovim integration harnesses
Add headless harnesses covering the calendar-vim integration, wired into CI alongside the existing keymap/config suites: - test-calendar-vim.sh/.vim (+ -optout.vim): pure-VimL diary hooks (calendar_sign markers, calendar_action path resolution from wiki root, calendar window close), plugin/nuwiki.vim hook auto-wiring that overrides calendar-vim's defaults, and opt-out via g:nuwiki_use_calendar and g:nuwiki_no_calendar. Uses a stub calendar-vim on the runtimepath. - test-calendar.sh/.lua: Neovim setup() wiring + window-close under the real window API, and opt-out via use_calendar = false. Fixes surfaced by the suite: - diary.vim: new diary entries set filetype 'vimwiki' (was the raw extension, e.g. 'wiki'); the stray FileType autocmd also blocked the calendar window from closing. - init.lua: drop the redundant Neovim FileType autocmd (plugin/nuwiki.vim already wires both editors) and translate use_calendar=false into g:nuwiki_no_calendar so the opt-out actually disables wiring. |
||
|
gffranco
|
7a3e11cfeb |
feat(calendar): integrate calendar-vim with wiki diary paths
Wire g:calendar_action/g:calendar_sign to nuwiki diary hooks that resolve diary paths from the wiki root config instead of calendar-vim's default ~/diary. Auto-detected on FileType vimwiki when calendar-vim is present; opt out with g:nuwiki_use_calendar=0 or g:nuwiki_no_calendar. - autoload/nuwiki/diary.vim: calendar_action/calendar_sign using wiki cfg; open diary in the previous window and close the calendar window after. - autoload/vimwiki/diary.vim: vimwiki# aliases for drop-in compatibility. - plugin/nuwiki.vim + lua/nuwiki/init.lua: auto-wire hooks, overwriting calendar-vim's defaults while respecting user-set custom hooks. - lua/nuwiki/config.lua: add use_calendar option (on by default). - development/start-*.sh + _common.sh: clone calendar-vim, fix vimrc var expansion, pass wiki root to the Vim/Neovim clients. |
||
|
gffranco
|
2da2168d88 |
fix(diary): complete the -count wiki selector (repair 874bdd0)
|
||
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
a15ae184a0 |
feat(client): bind bare gl/gL to remove-checkbox for vimwiki parity
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> |