Adds STOPPED alongside TODO/DONE/STARTED/FIXME/FIXED/XXX across the stack:
lexer, AST Keyword enum, HTML renderer (class="stopped"), LSP keyword_str,
and the Vim syntax red group (nuwikiKeywordAttn). Grouped with the
attention/pending keywords (red) for both export and in-editor highlighting.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
All keywords shared one `nuwikiKeyword` group linked to `Todo`, so the editor
showed TODO, DONE and XXX in the same colour. Split into nuwikiKeywordAttn
(TODO/FIXME/XXX, red) and nuwikiKeywordDone (DONE/FIXED/STARTED, green) with
explicit colours so the distinction survives any colorscheme — matching the
export's per-keyword classes.
Co-Authored-By: Claude Opus 4.7 <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>
Plain Vim spat a wall of `W18: Invalid character in group name` on
every buffer load because `syntax/vimwiki.vim` declared the
LSP-token highlight defaults with Tree-sitter-style names
(`@vimwikiHeading.level1`, `@vimwikiBold`, …). Those work on Neovim
but Vim rejects `@` and `.` in group names.
- `syntax/vimwiki.vim` now guards the `@vimwiki*` block with
`has('nvim')`. The static regex fallback below it (which uses
Vim-compatible `nuwiki*` group names) keeps highlighting working
on plain Vim.
While reproducing, also noticed `autoload/nuwiki/lsp.vim`'s
`s:bin_path` reported the binary at `/home/gfranco/bin/nuwiki-ls`
(only two dirs under `$HOME`) instead of
`/home/gfranco/git-repositories/nuwiki/bin/nuwiki-ls`. Cause:
`expand('<sfile>:p')` inside a function resolves to the *calling*
script at invocation time, not this autoload file. Captured the
plugin root via `<sfile>` at script-load time into a new
`s:plugin_root` and used it in `bin_path()`.
Verified with `vim -u .vimrc index.wiki`:
- `:messages` is empty of W18 warnings.
- The "binary not found" path (when no built binary exists) now
prints the correct repo-relative path.
Total 377 Rust tests still pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three reasons the plugin wasn't activating on `nvim --clean -u init.lua
foo.wiki`:
1. **File-name mismatch.** Vim's filetype-plugin runtime looks for
`ftplugin/<filetype>.vim` matching the *filetype name*. Our
filetype is `vimwiki` (per `ftdetect`) but the file was named
`ftplugin/nuwiki.vim` — so `:runtime! ftplugin/vimwiki.vim` from
the built-in FileType autocmd never found it, and none of the
`:Vimwiki*` / `:Nuwiki*` commands got defined. Same wart on the
syntax side. Renamed:
- `ftplugin/nuwiki.vim` → `ftplugin/vimwiki.vim`
- `syntax/nuwiki.vim` → `syntax/vimwiki.vim`
2. **`setfiletype` deferred to Neovim's bundled rule.** Neovim ships
a default `*.wiki → mediawiki` rule via `vim.filetype.add`, and
`:setfiletype vimwiki` is a no-op once a filetype has been set.
- `ftdetect/nuwiki.vim` now uses `set filetype=vimwiki` (force).
- `lua/nuwiki/init.lua`'s `setup()` also calls
`vim.filetype.add({ extension = { wiki = 'vimwiki', ... } })`
so the modern table-based detection picks us before the
bundled rule fires. Honours `config.options.file_extension`
so a user with a custom extension gets covered automatically.
3. **`foldmethod`/`foldexpr` are window-local options.**
`ftplugin.lua` was setting them with `nvim_set_option_value({ buf
= bufnr })`, which threw `'buf' cannot be passed for window-local
option 'foldmethod'` and aborted the rest of the per-buffer
attach. Switched to `vim.opt_local.*` (window-aware), applied on
the current window when the ftplugin fires, and re-applied via a
`BufWinEnter` autocmd so `:split` / `:vsplit` keep the fold mode.
Verified end-to-end with:
nvim --clean -u init.lua sample.wiki
→ filetype = vimwiki
→ :VimwikiTOC, :NuwikiIndex, … all defined
→ foldmethod = expr, foldexpr = v:lua.vim.lsp.foldexpr()
→ ftdetect, plugin, ftplugin, syntax all in :scriptnames
Total 377 tests still pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gffranco