- Remove fmt, clippy, cargo-test jobs (no Cargo.toml in this repo)
- Consolidate editor tests into a single job
- Remove release.yaml (binary build/release is in nuwiki-rs)
- Update ONBOARDING.md repo structure diagram
- Run CI on both Neovim 0.11 and latest
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.
The heading lexer required a space after the opening `=`s, so `==Heading==`
fell through to a literal `<p>==Heading==</p>` instead of an `<h2>`. vimwiki
accepts the spaceless form, so a migrated page whose top heading was
`==TODO==` (or `====Progress====`) rendered with no heading at all.
Drop the space-after-marker requirement; the existing title trim already
handles one optional space per side, so both `== H ==` and `==H==` work.
Marker-only (`======`) and unbalanced (`==a==b`, `==> x`) lines still stay
paragraphs (title-present + matching trailing-`=` checks). Regression tests
added at the lexer and renderer levels.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two export bugs reported against v0.4.0:
1. A heading whose text is a keyword (`== TODO ==`) rendered as an inline
`<span class="todo">` badge with an *empty* id, instead of a styled
header. Root causes: `inline_text` dropped Keyword nodes (so the heading
id/anchor came out empty, or `My TODO list` → `My list`), and the
keyword span was emitted inside the heading. Fix: `inline_text` now
includes the keyword's literal text (via new `Keyword::label()`), and
heading content renders keywords as plain text (flatten_keywords) so a
keyword title looks like a header. Keyword badges still render in body
text as before.
2. A `]` inside a wikilink description (e.g. `[[page|Task [B-1]]]`) closed
the link at the first `]]`, truncating the description and leaking a
stray `]`. The close-scan is now bracket-aware (find_wikilink_close):
inner `[ ]` pairs are balanced so the link closes at the correct `]]`.
Added regression tests for both.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`cargo fmt --check` (CI) flagged the hand-formatted destructure in the
lexer test and an over-long line in export.rs. No behavior change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Exported HTML diverged from upstream vimwiki's :VimwikiAll2HTML in ways
that break custom templates' CSS/JS and deep-links. Bring the renderer to
parity on the structural differences reported in #6:
1. Headings — restore vimwiki's structure: a wrapping
`<div id="{hierarchical}">` (parent anchors joined by `-`),
`class="header"`, and an in-heading `<a href="#{hierarchical}">`
self-link. The flat `id` stays on the heading element so intra-page
TOC / `#anchor` links keep resolving. Ancestor path is tracked while
walking top-level headings.
2. Code fences — emit vimwiki's `<pre {raw-attrs}>` (the verbatim text
after `{{{`, e.g. `<pre python>`) instead of
`<pre><code class="language-X">`, so highlighters wired for vimwiki
output apply. The fence text is now preserved verbatim through the
lexer/AST (PreformattedNode.attrs).
3. Inline tag ids — drop the `tag-` prefix (`id="wiki"`, not
`id="tag-wiki"`). Also fixes a real inconsistency: the LSP validated
`[[Page#wiki]]` as resolvable while the HTML emitted `id="tag-wiki"`,
so the exported link was broken.
4. Same-page anchors — `[[#Section]]` resolves to `index.html#Section`
(current page filename + fragment), matching vimwiki, rather than a
bare `#Section`.
Also ship vimwiki's stock style.css verbatim as the default stylesheet
(was a ~7-line minimal one) so exports look identical out of the box and
the `.header`/`.tag`/`.toc`/`done*` classes are styled.
Centered headings and the `<div class="toc">` Contents wrapper keep their
existing form. Tests updated across core + lsp to the new output; added
coverage for hierarchical ids, raw fence attrs, bare tag ids, and the
same-page anchor filename.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Releasing no longer means hand-editing the version across four files. The
Release workflow is now workflow_dispatch with a `version` input:
Actions → Run workflow → version: 0.4.0
A new `prepare` job validates the semver, runs scripts/set-version.sh to
stamp it into the workspace Cargo.toml, the two internal path-dep pins,
g:nuwiki_version, and the Cargo.lock entries for our crates; gates on
`cargo test --workspace`; then commits "chore(release): X.Y.Z" and pushes
the vX.Y.Z tag. The build matrix and release job run off that freshly
pushed tag (checkout ref = the new tag), so the tagged commit carries the
real version.
scripts/set-version.sh is the single source of truth for where the version
lives — run it locally with the same arg to bump by hand. It patches
Cargo.lock via awk so it needs no cargo/toolchain.
The push:tags trigger is removed (the pipeline now creates the tag itself,
so a tag-push trigger would double-fire).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bump workspace + internal dep pins + g:nuwiki_version to 0.3.0.
Since 0.2.0:
- feat(config): read g:vimwiki_list on Neovim too (lazy.nvim drop-in)
- feat(config): bridge setup({wikis}) to g:nuwiki_wikis for VimL plugins
- feat(calendar): diary into the current wiki, not always the first
- fix(lsp): resolve links from anywhere in the link, including the title
- fix(install): resolve release asset via Gitea API / direct URL; guard
download_bin.vim against 'compatible' mode
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
goto-definition (and references/hover) reported "No locations found" when
the cursor was on the *description* of a piped link — `[[target|Title]]`
or `[desc](url)` — and only worked over the target/location part.
find_in_inlines descended into the link's description and returned its
inner Text node, so the nav handlers saw a Text (not a WikiLink/
ExternalLink) and bailed. A link is an atomic unit for navigation: stop
descending into descriptions so a hit anywhere in the link returns the
link node itself. Adds a navigation regression test for cursor-on-title.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The VimL calendar-vim callbacks (nuwiki#diary#calendar_action /
calendar_sign) hardcoded wiki 0, so opening the calendar while editing
ifood_wiki still created/marked diary entries under the first wiki. (The
LSP-driven diary commands already follow the current buffer via its URI;
this brings the calendar in line.)
Track the wiki of the active buffer (nuwiki#diary#track_wiki, driven by
FileType/BufEnter autocmds in plugin/nuwiki.vim) and resolve the calendar
diary path against it, falling back to the first wiki. Verified the
calendar marker/open switch between wikis as you move between their
buffers. test-calendar-vim gains 4 multi-wiki tracking checks (16).
All keymap/config/calendar harnesses green on both clients.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
The dein/vim-plug build hook runs `vim -e -s -c "source scripts/download_bin.vim"`,
which starts in 'compatible' mode. There, leading-backslash line
continuations aren't recognised, so the multi-line URL string raised
`E10: \ should be followed by /, ? or &`. The install actually succeeded
(binary downloaded), but in silent Ex mode any emitted error makes Vim
exit non-zero — so dein reported a build failure. :NuwikiInstall worked
because a normal session is 'nocompatible'.
Wrap the script in the standard `let s:cpo_save = &cpo | set cpo&vim` …
`let &cpo = s:cpo_save` guard so line continuations parse regardless of
how it's invoked. Verified the exact dein command now exits 0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
: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>
`:VimwikiGenerateLinks <path>` sent nuwiki.links.generateForPath, but the
server had no handler and didn't advertise it — so the scoped form was
silently dropped (only the no-arg form worked). Register and implement it.
The page list is scoped via page_in_scope: a plain `path` is a directory
subtree (the page itself or anything under `<path>/`); a `path` with `*`/`?`
is a glob pattern (upstream's behaviour), matched with export::glob_match
(now pub(crate)). links_generate and the scoped form share
links_generate_scoped, so cursor-line insertion + captions + config all
apply uniformly.
Tests: page_in_scope unit tests (subtree, glob, prefix-sibling, trailing
slash) + COMMANDS advertises both generate forms. 580 passed, clippy
clean, harnesses green. Doc updated with the [path] argument.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
: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>
The g:vimwiki_* drop-in only fed the LSP payload (lsp.vim s:settings).
The buffer-side commands — <Leader>ww (wiki_index), :VimwikiSearch,
auto_chdir, diary, completion — resolve the wiki list independently via
s:wiki_cfg / nuwiki#commands#wiki_list, which read only g:nuwiki_wikis /
g:nuwiki_wiki_root. So with a g:vimwiki_list config the server knew the
wikis but <Leader>ww fell back to the default ~/vimwiki and opened an
empty index.
Extract the resolution into a single source of truth,
autoload/nuwiki/config.vim (nuwiki#config#wikis / #scalar_globals), which
resolves g:nuwiki_wikis or an upstream g:vimwiki_list and folds the global
scalar defaults. lsp.vim (payload), commands.vim, and diary.vim all route
through it — also dedups the s:wiki_cfg copy that lived in both
commands.vim and diary.vim.
Regression guard in test-vimwiki-compat-vim: nuwiki#commands#wiki_list()
must resolve the g:vimwiki_list roots (21 checks). All Vim harnesses +
config-parity goldens green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The start-vim-coc.sh harness runs `vim --clean`, so it never sources a
user's real vimwiki.vim — meaning g:vimwiki_list is never set and the
g:vimwiki_* drop-in translation was impossible to exercise through the
harness (you'd only ever test the native g:nuwiki_* path).
Add NUWIKI_DEV_VIMWIKI=1: instead of g:nuwiki_*, the generated vimrc
configures an upstream g:vimwiki_list (+ g:vimwiki_toc_header_level etc.)
pointing at the scratch wiki, so nuwiki's client-side translation +
programmatic coc registration run on a real vimwiki-shaped config.
NUWIKI_DEV_VIMWIKI=1 ./development/start-vim-coc.sh
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
coc users had to hand-maintain a coc-settings.json `languageserver.nuwiki`
entry, which didn't track g:nuwiki_wikis / g:vimwiki_list / the global
shorthand and meant editing JSON per wiki. nuwiki now registers itself
programmatically: on the first .wiki buffer it calls
coc#config('languageserver.nuwiki', {…}) with the s:settings() payload
(same config the vim-lsp path sends). coc reacts to the languageserver
config change (onDidChangeConfiguration → registerClientsByConfig) and
starts the server for the open buffer.
Details:
- Reliable coc detection via :CocConfig (exists('*coc#config') can't be
trusted — it doesn't trigger autoload in Vim 9.2). The coc#config call
is wrapped in try/catch and autoloads coc.vim itself; falls back to the
printed snippet only if coc genuinely isn't there.
- Deferred to User CocNvimInit when coc's node service isn't up yet.
- Opt out with g:nuwiki_no_coc_register (then we just print the snippet).
Dogfooded in start-vim-coc.sh: dropped the manual coc-settings.json
languageserver block; the harness now relies on auto-registration from
g:nuwiki_* (real-user flow). New harness test-coc-register-vim (7 checks,
stubbed coc#config) asserts the injected payload incl. the folded global
shorthand; wired into CI. README coc section rewritten (zero-config).
Rust 573 passed, clippy clean, all harnesses green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The start-* dev harnesses generated a minimal server config (wiki_root,
file_extension, syntax, log_level, diagnostic) with no display settings,
so :NuwikiTOC always produced `= Contents =` (level 1) regardless of code
changes — there was no way to test toc_header_level/html numbering through
the harness. The coc launcher is worst: coc reads coc-settings.json
verbatim, bypassing the Vim client's config translation entirely.
Set toc_header_level=2, html_header_numbering=2, html_header_numbering_sym
in all three launchers:
- start-vim-coc.sh: into the generated coc-settings.json (init + settings).
- start-vim.sh: as g:nuwiki_* globals (folded into the wiki via the global
shorthand).
- start-nvim.sh: in the setup() table.
Now the dev wiki demonstrates the settings: :NuwikiTOC writes
`== Contents ==` and HTML export numbers headings.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Two TOC bugs:
1. :NuwikiTOC ignored toc_header / toc_header_level (always "= Contents ="
at level 1). In the single-wiki shorthand the server only carried
file_extension/syntax from the top-level options into the synthesized
wiki; every other per-wiki key (toc_header, toc_header_level,
links_header, html_path, auto_export, …) was dropped. Add
single_wiki_from_value(), which re-parses the top-level object as a full
RawWiki (injecting root from wiki_root), so all per-wiki keys set at the
top level flow through. Wired into from_init_params + apply_change.
2. HTML export put class="toc" on the <hN> element, but upstream vimwiki
(and its stylesheet) wraps the TOC heading in <div class="toc">…</div>.
render_heading now emits the div wrapper, matching upstream so .toc CSS
applies. With (1) fixed, detection also works for a custom toc_header.
Tests: single_wiki_shorthand_honours_top_level_per_wiki_keys (config),
toc_header_heading_wrapped_in_div_toc + non_toc_heading_not_wrapped
(renderer). Full suite 572 passed; clippy clean; config-parity goldens
match.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 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
CI improvements:
- Add concurrency group to cancel redundant runs on same branch
- Add cargo cache to fmt job (was missing entirely)
- Add timeout-minutes: 5 to fast jobs (fmt, clippy, test) for fail-fast
- Change RUST_BACKTRACE from 'short' to '1' for better CI debuggability
- Pin push trigger to branches: [main] to avoid double-firing on PR merges
- Test minimum supported Neovim (0.11.0) instead of latest patch (0.11.3)
Release improvements:
- Enforce RUSTFLAGS: -D warnings at env level and in matrix rustflags
- Remove redundant checkout in release job (only needs env vars)
- Add release notes generation from git log since previous tag
- Make release creation idempotent (check if release exists before creating)
- Fix release_id not being set when release already exists
- Add NuwikiSearch to commands table (was incorrectly marked as Vimwiki-only)
- Add missing Vim globals: g:nuwiki_no_calendar, g:nuwiki_auto_chdir, g:nuwiki_auto_header
- Fix Plain Vim manual install to use cp instead of symlink (aligns with install() helper)
- Add missing <S-CR> insert-mode keymap to Lists keymaps table
- Clean up diary frequency section line wrapping
The parity work stream is complete. Forward-looking content (vimwiki
divergences, deferred features, internal deferrals) now lives in the
single source of truth, known-issues.md; the historical per-item
tracking log is preserved in git history. No code or docs reference the
file.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Exported HTML anchor links (TOC entries, [[Page#Heading]], [[#Heading]])
went nowhere because heading elements carried no `id`. Worse, the two TOC
builders slugified anchors (`#my-heading`) while the link resolver emits
the raw heading text (`#My Heading`, matching upstream vimwiki), so even
once ids existed the two halves wouldn't have agreed.
Fix — adopt vimwiki's scheme (raw heading text as the anchor) everywhere:
- render_heading emits `<hN id="<plain heading text>">`.
- build_toc_html (HTML export TOC) uses the raw, HTML-escaped title for
both the href and the link text (was slugify).
- collect_toc_items (:VimwikiTOC buffer output) uses the raw title for the
generated `[[#anchor]]` (was slugify). In-editor navigation slugifies
both sides, so it still resolves.
Consistency: add canonical `nuwiki_core::ast::inline_text()` and route the
heading id, the HTML-TOC title, the buffer-TOC title, and
`diagnostics::heading_text` through it — three duplicated extractors
collapsed into one, so the anchor and its validation can't drift.
Regression test: heading_id_matches_anchor_link_href (core) asserts the
heading id and a `#anchor` link's href are identical. Updated the heading
assertions in the renderer/export tests for the new `id=` attribute.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
s:resolve_index referenced an undefined `a:file` (a copy-paste leftover
from wiki_root_for, whose parameter is named a:file) inside the
buffer-owning-wiki loop. Any get_wikilocal() call with no explicit index
while a wiki buffer was current — i.e. the ftplugin BufRead path — hit
`E121: undefined variable a:file`. The local is `l:file`, and the
surrounding `!empty(l:file)` guard already covers emptiness, so the
clause was both wrong and redundant; removed it.
Add development/tests/test-vars-vim.{sh,vim} covering the shim:
per-wiki-index resolution, global-default fallback, out-of-range clamp,
the no-index owning-wiki path (direct guard for this E121), and the
single-wiki shorthand. Wired into CI. 14/14 pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Promote known-issues.md to the authoritative divergence reference ahead
of retiring development/vimwiki-gap.md:
- drop the pointer into vimwiki-gap.md so the file stands alone
- reframe the intro as the single source of truth
- add an "Internal deferrals (non-parity)" section capturing the
cold-path optimizations (RSS render_entry_body disk read,
push_level_edit_for_line offset scan, diary neighbor scan) that
otherwise only lived in the gap doc, so nothing is lost on deletion
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Consolidate the deferred features and intentional divergences from the
parity log (development/vimwiki-gap.md) into a user-facing reference:
- Deferred: the markdown generated-content cluster
(markdown heading generation, markdown_header_style, markdown_link_ext)
- By-design divergences grouped by area (highlighting/conceal -> LSP,
syntax detection, config mechanism, auto_tags, mouse maps, list_margin
negative + diary_caption_level -1 value semantics, Vim/Win shims)
- Default-location differences (html_path/template_path/diary_rel_path)
- Notes on the vars.vim compat shim and additive commands
Link it from the README "Migrating from vimwiki" section so it's
discoverable.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`vimwiki#vars#get_wikilocal(key, N)` previously ignored the wiki-index
argument and always read the scalar `g:nuwiki_*` globals (the first
wiki), so third-party plugins (vimwiki-sync, vim-zettel) got the wrong
wiki's path/ext/syntax in a multi-wiki setup.
Now:
- an explicit numeric index selects that wiki from `g:nuwiki_wikis[N]`,
falling back per-key to the scalar globals;
- with no index, the wiki owning the current buffer is resolved (matching
upstream's `g:vimwiki_current_idx` behaviour);
- an out-of-range index clamps to the first wiki.
The single-wiki shorthand path is unchanged. Verified with a headless
Vim test (by-index, global fallback, clamp, no-arg, shorthand) and the
Vim keymap harness (301/18/21, 0 failed).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Implements the deferred half of these options: a soft line break inside a
paragraph / list item can render as <br /> instead of a space.
- Parser: soft breaks now emit a dedicated InlineNode::SoftBreak node
(parse_inline_seq K::Newline + the list-continuation synthetic join) instead
of collapsing to Text(" "). Added SoftBreakNode + the variant.
- All inline consumers treat SoftBreak as whitespace: AST visitor (no-op),
text extraction (index.rs + lib.rs → space), nav/semantic_tokens span_of_inline,
semantic emit (skip like Text), parser span_of_inline.
- Renderer: render_inlines_break renders top-level SoftBreaks as the
context-specific string; render_paragraph uses text_ignore_newline,
render_list_item uses list_ignore_newline; default render_inline → space.
with_newline_handling builder; export.rs wires both from HtmlConfig.
Default (true/true = upstream default) behaviour is unchanged (space). Updated
3 core tests + 1 parser test that asserted the old Text(" ") shape to treat
SoftBreak as whitespace. New test render_page_html_ignore_newline_controls_soft_breaks.
Gap doc: P3 Config item closed — only the deferred markdown cluster remains.
Full rust suite + clippy clean; Neovim 307, Vim 301/18/21.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gffranco
gitea-actions
gffranco