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.
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.
A literal `<span style="color:…">` in prose (the sample wiki's own colorize
instructions used one, with a `…` ellipsis as the colour) was matched by the
scanner and fed to `highlight guifg=…`, which raised E254 on the un-silenced
guifg line. That aborted the whole nuwiki#colors#refresh(), so on the Vim
clients NO spans got concealed (start-vim) and follow-link crashed mid
FileType autocmd (start-vim-coc). Neovim happened to dodge it depending on
which buffer was scanned.
s:define() now:
- validates the colour (only #hex or an alphabetic name) and skips anything
else — rgb()/hsl() functions and prose examples no longer create bogus
conceal regions or errors;
- runs both `highlight` calls under `silent!`, so a valid-format but unknown
name can't abort the refresh either (tags still conceal, text just isn't
recoloured).
Also reworded the sample wiki's colorize note so it no longer embeds a
literal span tag.
Test: colorize.skips_unallocatable_colour (vim) — an rgb() span before a real
one: refresh doesn't error, the rgb span isn't concealed, the real span still
is. nvim 269, vim 260+18, all green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A :VimwikiColorize'd word showed the literal
`<span style="color:NAME">TEXT</span>` markup. Now the tags are concealed
and TEXT is painted in NAME, so the buffer shows just the coloured word —
matching the HTML export.
New autoload/nuwiki/colors.vim: nuwiki#colors#refresh() scans the buffer
and, per distinct colour, defines a syntax region that conceals the
`<span …>` / `</span>` tags (concealends) and highlights the body with the
span's actual colour (guifg always; ctermfg for named colours). Idempotent
(clears the group before redefining) and tracked in b:nuwiki_color_seen.
Refresh is driven from three places so it's both correct and immediate:
- syntax/vimwiki.vim: initial pass + re-establish after :colorscheme reload
(resets the per-buffer cache since :syntax clear drops the regions);
- ftplugin TextChanged/InsertLeave autocmd for spans that arrive via paste/
undo/external edits;
- colorize() itself calls refresh() right after wrapping, so a freshly
colorized word conceals instantly (TextChanged doesn't fire reliably mid
command / in headless ex-mode).
The LSP @vimwikiColor token no longer links to Constant, so in Neovim it
doesn't override the real per-span colour on the concealed text. Pure syntax
+ :highlight — works identically in Vim, coc.nvim, and Neovim, no LSP needed.
Tests: colorize.conceal_hides_tags_shows_text (both harnesses) and
colorize.command_conceals_immediately (vim). Sample wiki's colorize section
notes the conceal. nvim 269, vim 259+18, config-parity green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The sample wiki had no place to exercise :VimwikiColorize. Add a "Colour
spans" section to Syntax.wiki with words/phrases to wrap (and an already-
colorized span to render), plus a pointer in index.wiki's "Commands to
try" list. Lets the start-* launchers smoke-test the colorize fix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The launchers reused whatever was left under $XDG_CACHE_HOME/nuwiki-dev
between runs — seed_wiki() skipped reseeding when index.wiki already
existed, so stale edits from a previous session leaked into the next, and
old swap/viminfo/coc state carried over.
Each launch now starts clean:
- seed_wiki() reseeds the managed scratch wiki from a pristine copy every
run (rm -rf + write_sample_wiki). A user-pointed NUWIKI_DEV_WIKI is never
wiped — it's seeded only when empty, so a real wiki is never clobbered.
NUWIKI_DEV_NO_SEED still bypasses seeding entirely.
- new reset_dirs() helper wipes + recreates each launcher's owned state dirs
(vim viminfo/swap/undo, coc data, nvim XDG state/data/config) before launch.
Cached plugin clones (vim-lsp, async.vim, coc.nvim) are kept — only the
wiki and editor state are reset. Header docs updated to describe the
fresh-each-launch behavior.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gffranco
gffranco