Stock vimwiki templates and stylesheets rendered broken pages because the
HTML output diverged from vimwiki conventions on three fronts:
- Templates: the renderer only substituted nuwiki's `{{key}}` placeholders,
so vimwiki's `%title%`/`%content%`/`%root_path%`/`%date%`/`%wiki_css%`
passed through literally — dropping the body and breaking asset links.
Both delimiter styles are now recognised; `%wiki_css%` aliases the css var.
- Links: `[[todo.wiki]]` exported to `todo.wiki.html`. render_page_html now
takes the wiki file extension and strips it from wiki/interwiki targets
(via index::strip_wiki_extension) before the `.html` URL is built, matching
in-editor navigation. file:/local: links keep their literal extension.
- Tasks: checkbox items used bespoke `task-*` classes plus an `<input>`,
which double-rendered against vimwiki stylesheets. Emit `done0..done4`
(`[ ] [.] [o] [O] [X]`) and `rejected` (`[-]`) classes with no input — the
stylesheet draws the box.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The picker fetched the wiki list via workspace/executeCommand, but the LSP
only starts once a vimwiki buffer exists — so a wiki could not be selected
until one was already open (chicken-and-egg). Read the list straight from
config instead (g:nuwiki_wikis / scalar fallback, the same source as
open_wiki_path) and open the chosen index directly; that auto-starts the
server via the FileType autocmd.
- Vim: new public nuwiki#commands#wiki_list(); wiki_ui_select() uses it +
inputlist() + :edit. Global :VimwikiUISelect / :NuwikiUISelect commands.
- Neovim: config.wiki_cfg(n) + config.wiki_list() (init.lua delegates);
commands.wiki_ui_select() uses them + vim.ui.select + :edit; global
VimwikiUISelect / NuwikiUISelect user commands registered in setup().
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
concealcursor=nc kept the cursor's own line concealed in normal mode, so
the hidden characters of a wikilink ([[, target, ]]) still occupied buffer
columns — each l/h moved one hidden position with no visible movement,
making the cursor feel stuck. Drop the `n` flag (keep `c` for incsearch) so
the cursor line shows raw markup in normal mode while other lines stay
concealed.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pure rustfmt churn — the anchor-match, source-relative resolution,
and config-unwrap commits introduced lines that needed rustfmt
reformatting. CI's `cargo fmt --check` job was blocking on this.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Heading-block folds were computed but all collapsed on file open,
so users had to `zR` after every `:edit`. Set `foldlevel=99` once at
ftplugin attach so the fold structure is still there (closeable with
`zc`/`zM`) but the buffer renders fully expanded.
`foldlevel` is window-local; we set it on initial attach only — not
in the Lua BufWinEnter re-apply — so closing folds with `zc` in a
window survives navigating away and back to that buffer. Split
windows still get the same value because Vim copies window-local
options to the new window when splitting.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pressing <Tab> past the last cell unconditionally appended a new row
below, even when there was already a next row to jump into. Tabbing
through a header → separator → body table from the header row
inserted a blank row between header and separator instead of landing
in the first body cell.
After the final cell, walk forward from the current row to the end
of the table, skip any separator row, and jump to the first cell of
the next data row. Only insert a fresh row when the cursor is on the
table's last row (or only separator rows follow). Applied to both
the Vim (autoload/nuwiki/commands.vim) and Neovim (lua/nuwiki/
commands.lua) sides so the two harnesses stay in sync; covered by
new keymap tests in scripts/test-keymaps-vim.vim and test-keymaps.lua.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
`didOpen` for the wiki's index page fires almost immediately after
`initialized`, but the background `index_workspace` task hasn't yet
parsed the other pages. Link-health diagnostics computed at that
point look up every cross-page link target in a near-empty index and
flag them all as missing-page — and the diagnostics are never
recomputed once the scan catches up, so the editor shows stale red
squiggles on every link until the buffer is edited.
After each wiki's initial scan finishes, walk every open document
that lives in that wiki, recompute its diagnostics against the now-
populated index, and re-publish. Snapshots both the URI list and
each doc's `(ast, text, version)` so we don't hold DashMap iterators
across awaits.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
test-personal-wiki.sh wraps start-vim.sh to open the user's real wiki
at ~/.vimwiki/personal_wiki (override with NUWIKI_PERSONAL_WIKI) — used
when reproducing user-reported bugs against actual content instead of
the seeded smoke-test wiki.
Also adds a NUWIKI_DEV_NO_SEED env var to start-vim.sh so seed_wiki
doesn't drop a scratch Notes.wiki into the user's real notes when we
point WIKI_DIR at an already-populated wiki.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
`[[llm-wiki-pattern]]` in `tips/index.wiki` should resolve to
`tips/llm-wiki-pattern.wiki` — vimwiki's default is source-relative
for non-absolute targets. The index keyed every page by its
workspace-relative path, so the link looked up `llm-wiki-pattern`
(root-relative) and missed the sibling. Goto-definition then
synthesised a non-existent root URL, and `nuwiki.link` diagnostics
flagged every such link as missing-page.
- `WorkspaceIndex::resolve_wiki_path` and `page_for_wiki_target`
centralise the lookup: try `{source_dir}/{path}` first, fall back
to root-relative. Used by goto-definition, diagnostics, and the
workspace `checkLinks` walker.
- `collapse_dots` resolves `.` / `..` segments before lookup so
`[[../Other]]` from `posts/foo` correctly hits `Other` at the
wiki root (and is reported broken if no such page exists, rather
than silently going to nowhere).
- `canonical_link_name` applies the same rule when keying the
backlinks index, so backlinks queried by the resolved page name
pick up references that were written source-relative.
- `OutgoingLink` carries `is_absolute` now so `classify_outgoing`
(driven from cached index data, not the live AST) gets the same
treatment without re-parsing the source.
- `classify_outgoing`'s File/Local branch now reuses
`resolve_file_path` instead of duplicating the `//absolute` /
relative-to-source logic inline.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
`[[Page#Heading text]]` parsed the anchor as the literal string after
`#`, but the index stored each heading's anchor as `slugify(title)`.
The two never compared equal, so every TOC-style anchor link
(`[[#1. Topologia atual]]`, etc.) was reported as a broken anchor and
goto-definition couldn't jump to the right heading either.
Slugify the request before comparing — `slugify` is idempotent on
valid-slug input, so the same code path now accepts both
`[[Page#some-heading]]` (slug form) and `[[Page#Some Heading]]`
(raw text). Applied to diagnostics, navigation, and hover preview so
all three agree on what "an anchor matches a heading" means.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Drop-in script that dumps the syntax/highlight state of the current
buffer to /tmp/nuwiki-syndiag.log: filetype, b:current_syntax, every
syntax/vimwiki.vim found in &runtimepath (to spot duplicates from
other plugins), the resolved attributes of our highlight groups +
the colorscheme groups they link to, a per-segment synID walk over
the buffer, and the filtered scriptnames list. Useful when a user
reports broken highlighting and we need to know whether the patterns
aren't matching, the colorscheme is the culprit, or another plugin's
syntax/vimwiki.vim is winning the runtimepath race.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The single `nuwikiHeading` group linked all six levels to `Title`.
Many popular colorschemes (codedark, gruvbox-light, etc.) define
`Title` as bold-only with no foreground colour, so every heading
rendered as bold text in the Normal colour — H1 and H3 were
visually identical.
Split into nuwikiHeading1..6 and link each to a different accent
(Title / Function / Identifier / Type / Constant / PreProc), matching
the per-level Tree-sitter mapping the Neovim semantic-token side
already uses. The patterns are mutually exclusive: each requires
whitespace immediately after the equals run, so `=` won't match `==`.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two undefined targets meant bold/italic rendered as plain text:
- Neovim semantic-token defaults linked @vimwikiBold/Italic to
markdownBold/Italic, which only exist when the markdown treesitter
parser is loaded — never in a .wiki buffer. Use @markup.strong /
@markup.italic / @markup.raw.inline / @markup.link instead; those
are defined by every nvim 0.9+ colorscheme.
- The static fallback linked nuwikiBold/Italic to Bold/Italic groups
that exist in Neovim but not plain Vim, so on Vim the links
resolved to nothing. Define them with explicit gui=bold/italic
attributes so they render correctly everywhere.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Set conceallevel=2 and concealcursor=nc on .wiki buffers and add
contained `conceal` matches for the bold/italic/code delimiters and
wikilink brackets/targets. The static-fallback rendering now mirrors
what the Neovim semantic-token path produced: *bold* shows as bold
without the asterisks, [[target|desc]] shows just "desc", etc.
The wikilink region uses an inline `contains=` (no line continuation)
because some Vim builds (notably Homebrew Vim 9.2) raise E10 on the
leading `\\ contains=...` form even though the surrounding region
parses fine.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
`[[page.wiki]]` should resolve identically to `[[page]]`. The index
keyed by stem, so links with the explicit extension fell through to
the broken-link diagnostic and to-page navigation failed. Strip the
configured extension before every page lookup (resolve, definition,
backlinks, classify_link, classify_outgoing) and stop appending the
extension in synthesise_page_uri when it's already present.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
workspace/didChangeConfiguration settings from Neovim arrive as
{ "nuwiki": { "wiki_root": ..., "wikis": [...] } } because
server_settings() in lua/nuwiki/lsp.lua wraps the payload in a
"nuwiki" namespace key. apply_change() was trying to deserialise that
outer object directly as InitOptions, which always succeeded but produced
all-None fields (unknown keys are ignored by serde), so every settings
refresh was silently dropped.
Unwrap single-key objects whose value is also an object before
deserialising — this handles the Neovim wrapper while keeping the flat
VimL shape working unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
VimL dicts serialise boolean-like settings such as `auto_export = 1`
as the JSON number `1`, not `true`. serde's default `Option<bool>`
deserializer rejects that, causing `serde_json::from_value::<InitOptions>`
to return `Err` and `.ok()` to silently discard the entire wikis list.
The server then fell back to `wiki_root` and could not resolve per-wiki
links, marking every cross-wiki link as broken.
Add an `opt_bool_or_int` serde helper that accepts JSON bool, `null`,
or integers (0 = false, non-zero = true), and apply it to `auto_export`,
`html_filename_parameterization`, `listsyms_propagate`, and `auto_toc`
in `RawWiki`.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The server received only wiki_root (the parent directory) and had no
knowledge of the per-wiki sub-roots configured in g:nuwiki_wikis / the
setup() wikis list. It therefore resolved all links relative to the
parent root, causing every link in a sub-wiki to appear broken.
Vim path (autoload/nuwiki/lsp.vim):
s:settings() now includes a 'wikis' key when g:nuwiki_wikis is set,
so the initialization_options and settings payloads carry the full
per-wiki config (root, diary_rel_path, file_extension, …).
Lua path (lua/nuwiki/lsp.lua):
Add resolved_opts() which merges vim.g.nuwiki_wikis into
config.options.wikis when the user configures via VimL rather than
setup({wikis=…}). init_options(), server_settings(), and the
pre-0.11 root_dir_for() fallback all use resolved_opts() so the
server receives the correct per-wiki roots in every code path.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Commands were hardwired to vim-lsp (lsp#send_request, :LspDefinition,
:LspReferences, :LspRename). Users running coc.nvim got "vim-lsp not
loaded" on every command despite the plugin correctly detecting coc.
Changes:
autoload/nuwiki/commands.vim
- Add s:has_coc() (checks CocActionAsync exists)
- Add s:coc_wrap() adapter — converts coc's (err, result) callback into
the vim-lsp notification shape {response:{result:…}} so all existing
on_notification handlers work unchanged
- s:exec(): try vim-lsp first, fall back to CocActionAsync('runCommand',
…) with arguments spread as positional params, then error if neither
- Add s:jump_definition() helper — :LspDefinition vs CocActionAsync
- Add nuwiki#commands#backlinks() — :LspReferences vs CocActionAsync
- badd_link(): coc path uses CocAction('getDefinition') to resolve the
target URI without navigating
- follow_link_or_create(): replace inline :LspDefinition checks with
s:jump_definition()
- rename_file(): :LspRename vs CocActionAsync('rename')
ftplugin/vimwiki.vim
- VimwikiFollowLink / NuwikiFollowLink: dispatch through
nuwiki#commands#follow_link_or_create() instead of :LspDefinition
- VimwikiBacklinks / NuwikiBacklinks / VWB: dispatch through
nuwiki#commands#backlinks() instead of :LspReferences
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
<sfile> inside a command! body is evaluated at execution time, not at
definition time. When :NuwikiInstall is run interactively there is no
sourcing context, so <sfile> expands to nothing and the path collapses
to ./scripts/download_bin.vim — producing E484.
Fix: capture the path in s:plugin_root immediately while the script is
being sourced, then reference that variable from the command body.
Also hoist :NuwikiInstall above the early `finish` for Neovim so the
command is available in both editors (Neovim routes to
require('nuwiki.install').install(), Vim sources the download script).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The global <Leader>ww / diary helpers read g:nuwiki_wiki_root directly,
so they always opened the root-level index.wiki even when the user had
configured per-wiki roots via g:nuwiki_wikis (e.g. personal_wiki.root =
'~/.vimwiki/personal_wiki').
Vim path (autoload): replace the three open_*_path functions with a
shared s:wiki_cfg(n) helper that checks g:nuwiki_wikis[n] first, then
falls back to the scalar g:nuwiki_* vars and built-in defaults.
Lua path (init.lua): replace the separate _wiki_index_path /_diary_path
locals with a unified _wiki_cfg() that checks setup() opts.wikis, then
vim.g.nuwiki_wikis (for users who configure via VimL rather than
setup()), then scalar opts / g: vars.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Third-party plugins such as vimwiki-sync and vim-zettel call
vimwiki#vars#get_wikilocal() — a function only provided by the original
vimwiki plugin. Without it, the after/ftplugin loaded by vimwiki-sync
errors on every wiki buffer open:
E117: Unknown function: vimwiki#vars#get_wikilocal
E121: Undefined variable: g:zettel_dir
Add autoload/vimwiki/vars.vim with lightweight stubs for the two keys
vimwiki-sync uses ('path', 'is_temporary_wiki'), reading values from
nuwiki's own g:nuwiki_wiki_root / g:nuwiki_file_extension config so
users don't have to duplicate settings. get_global() is stubbed as a
no-op for completeness.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two bugs prevented keymaps from working after a Dein install:
1. <Leader>ww and <Leader>wt both called diary_today() instead of
wiki_index() / wiki_tab_index(). Fixed in keymaps.lua (Neovim)
and ftplugin/vimwiki.vim (Vim).
2. All keymaps were buffer-local (<buffer> / buffer=bufnr), so they
only activated inside an already-open .wiki file. Users had no way
to reach the wiki from any other buffer, making the plugin appear
broken on a fresh Vim start.
Fix: register the eight <Leader>w* entry-point mappings globally —
in setup() for Neovim (lua/nuwiki/init.lua) and in plugin/nuwiki.vim
for plain Vim. To avoid a chicken-and-egg LSP dependency, the global
mappings open files directly from config (wiki_root, diary_rel_path,
file_extension); the LSP auto-starts via the FileType autocmd once
the vimwiki buffer loads. Three new autoload helpers
(open_wiki_path, open_diary_path, open_diary_index_path) provide the
LSP-free path for the Vim side.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
gcc-aarch64-linux-gnu ships the cross compiler and binutils only;
linking glibc binaries also requires the target libc crt/dev files
(Scrt1.o, crti.o), which live in libc6-dev-arm64-cross.
Without it, the aarch64-unknown-linux-gnu build failed with:
ld: cannot find Scrt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
actions/upload-artifact@v4 and download-artifact@v4 require the
GitHub-hosted artifact backend, which Gitea Actions does not
implement (GHESNotSupportedError on v2.0.0+). Downgrade to v3.
v3's download-artifact has no merge-multiple flag and nests each
artifact under artifacts/<artifact-name>/, so the upload loop now
recurses to find the archives.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cross spawns Docker containers per target, but the Gitea Actions
runner doesn't expose /var/run/docker.sock, so every cross-compile
step died with "Cannot connect to the Docker daemon".
Replace with rustup-installed targets plus per-target linker setup:
- x86_64-gnu: native (no extra deps)
- aarch64-gnu: gcc-aarch64-linux-gnu from apt
- x86_64-musl: musl-tools from apt
- aarch64-musl: rust-lld + link-self-contained (rust-std bundles
musl libc.a + crt, no apt deps needed)
Verified aarch64-musl path locally: produces a statically linked
ARM aarch64 ELF.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The prior commit (e849ac9) intentionally removed the h1-only
restriction from find_section_range so VimwikiGenerateTagLinks stays
idempotent under non-h1 tag headings. The accompanying test still
asserted the old h1-only behavior and now fails.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CI's cargo fmt --check flagged a few lines from the propagation patch
that exceeded the wrapping threshold. No behavioural change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
nvim defaults autoindent=on, so the indent inserted by Vim/Nvim after
the <CR> we return was being doubled by our own indent prefix —
pressing Enter on a sub-item produced a deeper-nested item instead of
a same-level one. Detect any auto-indent mechanism (autoindent,
smartindent, cindent, indentexpr) and let it own the indentation;
otherwise add it ourselves so vim's noautoindent default still works.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ensure_binary used to short-circuit whenever bin/nuwiki-ls existed,
which left vim/nvim running an outdated LSP after every source change.
Now always invoke cargo build (incremental, so a no-op when nothing
changed) and refresh the symlink + log the build timestamp. Add
NUWIKI_DEV_SKIP_BUILD=1 for the rare opt-out.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Toggling/cycling/rejecting a nested checkbox now recomputes each
ancestor's progress marker (vimwiki's listsyms_propagate). Mirrors
vimwiki's averaging — rejected items count as 100% unless every child
is rejected, in which case the parent itself becomes rejected. Walks
up while each ancestor has its own checkbox.
Also tightens find_checkbox_span to scan only the marker line, since a
parent item's span covers its nested sublist and was matching child
markers as if they belonged to the parent.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The keymap harness caught a regression in 5b6f789: returning '' from
the <expr> mapping and deferring cursor placement to vim.schedule
breaks any keypress immediately following Tab/<CR>. nvim_feedkeys with
the 'x' flag drains all queued keys synchronously, so the user's next
key lands at the pre-jump cursor position — and the scheduled
callback's startinsert leaks insert mode into the next test.
Mirror what the VimL side already does: have <expr> return
"<Cmd>lua require('nuwiki.commands')._helper(args)<CR>" so the
align + cursor-jump runs synchronously inside the same keypress. No
schedule, no mode juggling.
cr.adds_new_table_row ✓
tab.next_cell_in_table ✓
tab.from_first_cell_moves_to_second ✓
shift_tab.prev_cell_in_table ✓
39/39 in scripts/test-keymaps.sh (was 35/4-fail).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Restructures the integration test layout so each file is named after
what it covers, not the implementation phase it landed in.
nuwiki-core (renames only):
vimwiki_lexer → lexer
vimwiki_parser → parser
vimwiki_tags → tags
vimwiki_table_alignment → table_alignment
diary_period → diary
list_continuation → lists
transclusion_attrs → transclusion
+ table colspan/rowspan tests moved here from parity_cluster_1
nuwiki-lsp (renames + merges + one split):
cluster_a_list_rewriters → commands_lists
cluster_b_table_rewriters → commands_tables
cluster_c_link_helpers +
phase19_followlink_creates → commands_links
phase13_rename_commands → commands_files
phase17_colorize → commands_colorize
phase17_html_export → html_export
phase15_link_health → link_health
phase18_multi_wiki → multi_wiki
phase19_folding → folding
nav → navigation
lsp_helpers → helpers
phase16_diary +
diary_frequency → diary
phase11_plumbing +
parity_cluster_1 (config) → index_and_config
tags_index_and_lsp +
phase17_backfill → commands_tags
phase14_edit_commands → split into
commands_checkboxes,
commands_headings,
commands_tasks
Net: 30 → 28 integration-test files. 456 → 455 tests (the one
removed test was a dummy `paragraph_render_is_unchanged` whose only
purpose was to keep a `ParagraphNode` import alive in
parity_cluster_1; the import is exercised elsewhere now).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two bugs in the insert-mode table editing path:
1. <Tab> past the last cell (and <CR> on a table row) used <CR>+typed
keystrokes to create a new row, which split the current line at the
cursor — pulling the trailing | down onto the next line and mangling
the formatting. Both paths now go through helpers that append() a
fresh row beside the current one without touching it.
2. The table never realigned to new content. Ported the LSP-side
render_aligned_table algorithm to Lua + VimL so smart_tab,
smart_shift_tab, and smart_return tighten column widths locally on
every navigation. No vim-lsp / nuwiki server roundtrip required.
Neovim side schedules the work via vim.schedule (textlock-safe);
plain Vim hands off via <Cmd>:call …<CR> to keep insert mode and
avoid the cmdline-mode flash.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both files now describe what the plugin DOES, with no references to
internal phase work or SPEC.md (which is dev-only).
README.md
* Reorganised the feature list by area (syntax, editor intelligence,
editing, diary, other) and surfaced everything actually shipped:
text objects, smart `<CR>` / `<Tab>` in insert, table alignment
markers, colspan/rowspan, transclusion attributes, diary
frequencies, list continuation, etc.
* Updated the keymaps table to include the full insert-mode bindings,
list-rewriter shortcuts (`gLh`/`gLl`, `glr`/`gLr`, `gl<Space>`),
and all five text-object pairs (was "ah/ih + planned follow-ups").
* Expanded the configuration example with the per-wiki keys (diary,
HTML export, listsyms, nested_syntaxes) and the new Vim globals
(`g:nuwiki_no_folding`, `g:nuwiki_mouse_mappings`).
* Dropped the architecture / repository-layout / phase-log sections.
Contributors who care about those still find them in the codebase.
* Removed the "two known behavior deltas" note — the gln/glp claim
is no longer accurate (both bindings ship as separate keymaps),
and the lazy-index caveat moved into the Migrating section.
doc/nuwiki.txt
* Grew from 7 sections to 14 covering installation, configuration
(top-level + per-wiki + Vim globals), commands, keymaps (by area),
text objects, insert-mode bindings, diary (with frequency formats),
tables (with alignment / span syntax), HTML export, folding, health
checks, and migrating from vimwiki.
* Every public command has a help anchor.
* Removed the §6.9 spec reference and the phase 9 caveat.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Close the remaining Vim-vs-Neovim functional gaps:
* Text objects — new `autoload/nuwiki/textobjects.vim` mirroring
`lua/nuwiki/textobjects.lua`. All five pairs (ah/ih, aH/iH,
al/il, a\/i\, ac/ic) wired in the Vim path of `ftplugin/vimwiki.vim`
via the classic `:<C-u>call` idiom that works cleanly in both
operator-pending and visual modes.
* Folding — new `autoload/nuwiki/folding.vim` providing a regex
`foldexpr` over headings, plus a tidy `foldtext`. Wired in the
Vim path; opts out via `let g:nuwiki_no_folding = 1`.
* `smart_return` was using `setline()` / `append()` inside an
`<expr>` callback — fine on Neovim but plain Vim's stricter
textlock raised E565. Rewrote as pure keystrokes (matches the
Lua version): table rows insert via `<CR>...<Esc>0li`, empty
list lines break via `<Esc>0DA<CR>`.
* Function-name parity: added
`nuwiki#commands#heading_add_level`,
`nuwiki#commands#heading_remove_level`,
`nuwiki#commands#table_move_column_{left,right}` as thin
aliases over the original short names so the public
`nuwiki#commands#*` surface matches `require('nuwiki.commands').*`.
Test harness:
* `scripts/test-keymaps-vim.vim` extended from 12 to 30 cases:
4 smart_return, 3 smart_tab/<S-Tab>, 3 named-command exists,
4 text-object helpers, 1 `dah` end-to-end, 2 folding, and the
original 12 pure-VimL cases. (Visual-mode mark inspection in
`vim -e -s` stays unreliable, so text objects are exercised
at the helper level plus one operator-pending end-to-end.)
Gates: 456 Rust / 39 Neovim / 30 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lines indented strictly past a list item's marker now attach to that
item rather than becoming a sibling paragraph. Matches upstream
vimwiki + Markdown convention.
Before:
- first item
continuing here ← rendered as a separate <p>
- second
Now:
- first item continuing here ← one <li>, joined with a space
- second
The detection lives in `parse_list_item`: after the item's first
line, we loop over subsequent lines and treat each as continuation
when its leading whitespace exceeds the marker's column. Two
flavours need handling because the lexer emits different tokens
based on indent width:
* 1..3 leading spaces → `Text(s)` with the whitespace embedded;
we trim it off the first text token before re-running
`parse_inline_seq`.
* 4+ leading spaces → `BlockquoteIndent` + bare `Text`; we
advance past the indent token and use the text as-is.
Continuation also works inside nested lists (`level + 1` threshold
adapts to the marker's own indent) and is bounded by blank lines /
unindented content / sibling-or-shallower list markers.
Tests: 6 new in `crates/nuwiki-core/tests/list_continuation.rs`
covering single-line continuation, multi-line continuation, blank-
line termination, unindented termination, nested-list continuation,
and the HTML-renderer regression (single `<ul>` with two `<li>`s,
no orphan `<p>`).
Gates: 456 Rust / 39 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vimwiki's `diary_frequency` config has been honoured by the existing
`nuwiki.diary.openToday` / `openYesterday` / `openTomorrow` commands
end-to-end. Setting `diary_frequency = 'weekly'` (or `monthly` /
`yearly`) now creates and addresses entries at that cadence — file
stems follow the canonical formats:
daily YYYY-MM-DD 2026-05-12.wiki
weekly YYYY-Www 2026-W19.wiki (ISO 8601 week)
monthly YYYY-MM 2026-05.wiki
yearly YYYY 2026.wiki
Core additions (nuwiki_core::date):
- DiaryFrequency enum + permissive `parse` (unknown → Daily)
- DiaryPeriod enum unifying Day / Week / Month / Year
- format / parse / next / prev / today_utc + first_day, with
proper ISO-week math (Thursday rule, year-boundary handling)
LSP wiring:
- WikiConfig::frequency() and diary_path_for_period()
- crate::diary::uri_for_period
- Index now records `diary_period` for any of the four flavours;
`diary_date` is preserved (filtered to Day-only) for back-compat
with existing daily-only callers
- `nuwiki.diary.next` / `nuwiki.diary.prev` now navigate at the
*same flavour* as the current entry (or at the wiki's configured
frequency when off a diary page), via new
`crate::diary::next_period` / `prev_period` helpers
- `nuwiki.diary.openToday` returns the period stem + frequency in
its response payload alongside the URI
Tests:
- 12 in crates/nuwiki-core/tests/diary_period.rs covering the date
math (ISO week boundaries, format round-trips, next/prev across
year edges, etc.)
- 9 in crates/nuwiki-lsp/tests/diary_frequency.rs covering
WikiConfig path computation, index recognition for all four
stems, period navigation, and diary-dir filtering
Gates: 450 Rust / 39 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`{{url|alt|key="quoted value"}}` syntax was already parsed end-to-end
through to `TransclusionNode::attrs`, but the value retained the
surrounding `"…"` (or `'…'`) characters verbatim. The HTML renderer
then escaped them into `"`, producing `style=""border: 1px""`
instead of clean `style="border: 1px"`.
Extracted a small `insert_attr` helper that splits on `=`, trims, and
strips matching single- or double-quote pairs from the value before
inserting. Unquoted values pass through unchanged.
Tests: 4 new in crates/nuwiki-core/tests/transclusion_attrs.rs
covering double-quote stripping, single-quote stripping, unquoted
pass-through, and the clean-HTML rendering shape (no `"`).
Note: this commit covers the "transclusion attrs" half of the
original Cluster 8 audit. The "multi-line list-item continuation
paragraphs" half requires lexer + parser changes (continuation lines
indented past the marker should attach to the prior list item
instead of becoming a sibling paragraph) and is deferred.
Gates: 429 Rust / 39 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Markdown-style alignment anchors on a table's header-separator
row now propagate from the lexer through the parser into the AST,
and the HTML renderer emits a `style="text-align: …;"` attribute on
each affected `<th>` / `<td>`.
|:--| → left
|--:| → right
|:--:| → center
|---| → default (no style attr)
Encoding choice: rather than threading the source string into the
parser, the lexer now extracts per-cell alignment when it recognises
the separator row and carries the `Vec<TableAlign>` inline on the
`TableHeaderRow` token. The parser unpacks it into `TableNode`'s
new `alignments: Vec<TableAlign>` field. Cells past the end of the
vector render with the default alignment.
`TableAlign` lives in `nuwiki_core::ast::block` alongside the table
nodes and is re-exported via `nuwiki_core::ast`.
Tests: 4 new in crates/nuwiki-core/tests/vimwiki_table_alignment.rs
covering plain dashes, all three anchor flavours, the HTML output
shape, and the no-style-attr case. The existing
`vimwiki_lexer::table_header_separator_row` was updated to assert
the new payload shape.
Gates: 425 Rust / 39 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`<Tab>` / `<S-Tab>` in insert mode navigate between table cells when
the cursor is on a `|…|` row, otherwise they pass through to their
default insert-mode behaviour (literal tab / shift-tab). Same
`<expr>`-mapping idiom as Cluster 5's smart_return.
<Tab> next cell; creates a fresh row below if past the last cell
<S-Tab> previous cell; no-op past the first
Cursor lands immediately after the destination cell's leading `|`,
matching upstream vimwiki's `vimwiki#tbl#go_*_cell` behaviour.
Both Lua and VimL counterparts wired into ftplugin's existing
table_editing block (gated alongside `gqq`/`<A-Left>`).
Tests: 4 new in scripts/test-keymaps.lua — next cell, new-row
overflow, previous cell, and pass-through outside a table.
Gates: 421 Rust / 39 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bind `<CR>` in insert mode as an `<expr>` map to a `smart_return`
helper. Behaviour matches upstream vimwiki's `:VimwikiReturn`:
- On a list line with content → continue the list with the same
marker on a new line (preserving leading checkbox `[ ]` if any).
- On an empty list line (marker only) → clear the marker and break
out of the list with a plain newline.
- Inside a `|…|` table row → insert a fresh empty row below with
the same column count, cursor lands inside the first cell.
- Otherwise → plain `<CR>`.
Implementation note: the helper is `<expr>`-bound, which means
textlock is active and the buffer can't be mutated from inside the
callback. The function returns key sequences only — including
`<Esc>0DA<CR>` for the empty-list break and `<Esc>0li` for the
table-row cursor jump — so every effect flows through Vim's normal
keystroke pipeline and stays undo-coherent.
Both Lua and VimL counterparts shipped.
Tests: 4 new in scripts/test-keymaps.lua covering list continuation,
checkbox preservation, empty-marker break-out, and new table row.
Gates: 421 Rust / 35 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five operator-pending + visual text-object pairs, matching upstream
vimwiki:
ah / ih heading section only (stops at any next heading)
aH / iH heading section + sub-tree (stops at same-or-shallower)
al / il list item (line, with / without marker prefix + checkbox)
a\ / i\ table cell (with / without surrounding `|` separators)
ac / ic table column (with / without the header separator row)
Pre-existing `ah` used aH semantics — fixed to match vimwiki: `ah`
now stops at the next heading regardless of level. `aH` is the new
descendants-inclusive variant.
Implementation notes:
- Pure regex; no LSP round-trip. Each helper computes a `(line, col)`
rectangle and drives the selection with feedkeys.
- Operator-pending and visual need different feed sequences. In visual
the previous anchor is sticky, so bounce through `<Esc>` first. In
operator-pending an `<Esc>` would CANCEL the pending operator —
feed the visual keys directly so Vim treats them as the motion.
- Re-exported helpers (`_heading_block`, `_cell_ranges`,
`_current_cell_for_line`, `_table_bounds`) keep the integration
surface testable without going through Vim's visual-mode pipeline,
whose `'<`/`'>` mark semantics fight headless test harnesses.
Tests: 6 new in scripts/test-keymaps.lua — five pure-helper cases
plus one end-to-end `dah` deletion to verify the operator-pending
wiring.
Gates: 421 Rust / 31 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Match upstream vimwiki's insert-mode list editing:
<C-D> list_change_level(-1) dedent current item
<C-T> list_change_level(+1) indent current item
<C-L><C-J> list_cycle_symbol(+1) cycle marker forward
<C-L><C-K> list_cycle_symbol(-1) cycle marker backward
<C-L><C-M> list_toggle_or_add_chk toggle if has checkbox, else add `[ ]`
Cycle order matches vimwiki's canonical run:
- → * → # → 1. → 1) → a) → A) → i) → I) → (wrap)
Both Lua and VimL paths wired. Lua callbacks fire directly (no `<C-o>`
dance) since list_change_level / changeSymbol mutate the buffer via
the LSP applyEdit pipeline, which works cleanly in insert mode. VimL
keeps the `<C-o>:call …<CR>` idiom since that's the standard there.
Harness adds 5 cases covering the new insert-mode bindings plus one
direct LSP roundtrip for changeSymbol — surfaced a long-standing
stale-binary footgun in test-keymaps.sh (rebuilt only when bin was
missing; now rebuilds every run since incremental cargo is fast).
Harness also captures server log_messages and dumps them on failure
so future swallowed-error bugs (Err → log + Ok(None)) are visible.
Gates: 421 Rust / 25 Neovim / 12 Vim.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
named link commands, mouse maps
Parity audit Cluster 1 — small wins.
WikiConfig (server) extended with 14 vimwiki globals:
- `index` (`g:vimwiki_index`), wired into `:VimwikiIndex` so users
with a custom index page stem (e.g. `home`) get the right file.
- `diary_frequency`, `diary_start_week_day`, `diary_caption_level`,
`diary_sort`, `diary_header` — diary keys (weekly/monthly/yearly
semantics land in Cluster 4; the keys parse now so config
migration doesn't need to wait).
- `maxhi`, `listsyms`, `listsyms_propagate`, `list_margin`,
`links_space_char`, `nested_syntaxes`, `auto_toc` — list +
highlight knobs the renderer/handlers can consult.
All keys threaded through `RawWiki` → `WikiConfig::from(RawWiki)`,
defaults centralised in `wiki_defaults()` so `empty()`, `from_root()`,
the legacy single-wiki path, and the `RawWiki` impl stay in sync.
Lua front-door (`lua/nuwiki/config.lua`) now documents the multi-wiki
`wikis = {…}` shape with every accepted per-wiki key — users who
prefer Lua tables no longer have to round-trip through
`init_options` raw JSON.
HTML renderer (`crates/nuwiki-core/src/render/html.rs`):
- New `table_spans()` pre-pass resolves vimwiki's `>` (col_span) and
`\\/` (row_span) continuation markers into proper HTML
`colspan="N"` / `rowspan="N"` attributes on the lead cell. Continuation
cells emit nothing, matching what browsers expect.
- The old behaviour (emitting `class="col-span"` / `class="row-span"`
as visual markers) is gone — replaced with real merging so the
rendered HTML matches the source semantics.
Named ex-commands:
- `:VimwikiNextLink` / `:VimwikiPrevLink` — were keymapped only
(`<Tab>`/`<S-Tab>`); now have explicit `:` commands in both editor
paths, dispatching to new `nuwiki.commands.link_next` / `link_prev`
pure-Vim/Lua helpers.
- `:VimwikiBaddLink` — adds the link target's file to the buffer
list without switching focus. Goes through
`textDocument/definition` and runs `:badd <fname>` on the resolved
URI.
Mouse maps (opt-in via `mappings.mouse = true` in Lua or
`g:nuwiki_mouse_mappings = 1` in Vim):
- `<2-LeftMouse>` follows, `<S-2-LeftMouse>` / `<C-2-LeftMouse>`
follow in split/vsplit, `<MiddleMouse>` adds to buflist,
`<RightMouse>` goes back. Mirrors upstream vimwiki's defaults.
Tests: 7 new in `parity_cluster_1.rs` covering the per-wiki config
defaults + raw JSON parse, the legacy-single-wiki path, colspan
folding into a lead cell with no leftover class markers, rowspan
across rows, no-attrs when the table has no spans, and a sanity
paragraph render. Total 421 Rust tests pass; clippy clean; both
keymap harnesses still green (20 nvim + 12 vim).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the last pending §13.1 entries:
- **`nuwiki.colorize`** (client-side, Lua + VimL) — wraps the word
at cursor (or the visual selection on Neovim) in an inline
`<span style="color:%c">…</span>` template. Matches vimwiki's
default `color_tag_template`. Bound to `<Leader>wc` in both
normal and visual mode on both editor paths; the previous
"deferred" stub is gone.
- **`color_dic` → renderer** — `HtmlConfig` gains a
`color_dic: HashMap<String, String>` field reading the same key
out of `initializationOptions` / `didChangeConfiguration`. The
HTML export path threads it into `HtmlRenderer::with_colors`;
`ColorNode` now picks `style="color:<value>"` when the colour
name is in the dict, falling back to the existing
`class="color-<name>"` when it isn't.
SPEC §13.1 is fully checked off — the table moved from "deferred
sketch" to a per-command status table marking all 11 commands done,
plus a note on the `color_dic` follow-up landing alongside. README's
"Phase 14 list & table edit commands" row now reads ✅ without the
deferred-subset caveat, and the §13.1-blocked text-objects note in
the keymaps section is rephrased as "planned follow-ups".
Tests: 4 new in `phase17_colorize.rs` covering the renderer
fallback when the dict is empty, the inline-style emission for a
listed name, the fallback path for an unlisted name in a populated
dict, and the `initializationOptions` JSON shape. Total 414 Rust
tests pass; clippy clean; keymap harness still 20/20.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the table-rewriter cluster from SPEC §13.1.
Server-side (ops module):
- `render_blank_table(cols, rows)` — pure templating: header row,
separator `|--|--|--|`, then `rows` empty data rows. Wired through
`table_insert` which dispatches a `TextEdit` at the cursor.
- `table_align_edit` — locates the `TableNode` containing the cursor
line, computes max width per column across every row, re-emits the
table with each cell space-padded to its column's width. The
parser drops `|---|---|` separator rows but sets
`TableNode.has_header`; the renderer re-inserts a padded separator
after the header so the result still parses.
- `table_move_column_edit` — column-under-cursor swap with the
left or right neighbour (`dir = "left" | "right"`). Cursor column
is computed by counting pipe separators before the cursor's byte
offset on the row's line. Column widths swap alongside the data so
the post-swap table stays aligned. No-ops cleanly when the swap
would fall off either edge.
Editor glue:
- `lua/nuwiki/commands.lua` / `autoload/nuwiki/commands.vim` — the
three "not yet implemented" stubs are replaced with real LSP
dispatchers. `table_insert` accepts optional `cols`/`rows`
arguments (defaults: 3×2).
- Default keymaps `gqq` / `gq1` / `gww` / `gw1` now call
`table_align`; `<A-Left>` / `<A-Right>` call
`table_move_column_left` / `_right`. No more "deferred"
notifications on the table keys.
Tests: 8 new in `cluster_b_table_rewriters.rs` — blank-table shape
(3×2 + 1×1), column-width alignment with separator-row repad, swap-
right shape, swap-left clamp at column 0, no-table-found fallbacks,
COMMANDS list completeness. Total 410 Rust tests pass; clippy clean;
Neovim keymap harness still 20/20.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gffranco