gffranco
6efe154f1a
`textDocument/semanticTokens/full` + `/range` per SPEC §6.9. Token
type scheme settled in P7: custom `vimwiki*` types
(`vimwikiHeading`, `vimwikiBold`, `vimwikiCodeBlock`, `vimwikiKeyword`,
`vimwikiWikilink`, `vimwikiTransclusion`, …) plus `level1`..`level6`
and `centered` modifiers. Default highlight groups for these arrive
in Phase 9.
Pipeline (`semantic_tokens.rs`):
- `legend()` builds the `SemanticTokensLegend` advertised in
`initialize` capabilities.
- `LineIndex` precomputes byte offsets per line so multi-line span
splitting and UTF-16 conversion stay linear.
- `collect_tokens` walks the AST. Blocks that are visually distinct
(heading, preformatted, math-block, comment) emit one token over
their span; multi-line ones get split per line because the LSP wire
format can't represent a token that crosses a newline. Container
blocks (paragraph, list item, table cell, blockquote) recurse into
inlines instead of wrapping them, so we end up with a non-overlapping
tile of inline tokens. Headings shadow nested inlines (one heading
token covers the line, no Bold-inside-Heading).
- `encode` produces the LSP delta-quintuple stream
`(deltaLine, deltaStart, length, type, mods)`. UTF-16 mode converts
byte offsets/lengths to code-unit counts on the fly (BMP + surrogate
pairs).
- `build_data` is the entry point used by both handlers; the `range`
variant filters tokens by overlap in the same encoding the client
requested.
Capability declared as `SemanticTokensOptions { full = true,
range = true, legend = … }`. Both handlers reuse the document store.
P7 resolved in SPEC §11 — custom vimwiki types with rationale and a
note that Phase 9 will ship default highlight-group definitions in
`syntax/nuwiki.vim` and the Lua glue.
Tests (21 new): legend integrity, per-construct emission for every
inline + block kind, heading shadowing of inner inlines, multi-line
code/math block splitting, sort order, delta encoding (same line and
crossing lines), UTF-16 length conversion for é, range filter,
empty-doc edge case, end-to-end `build_data` parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
nuwiki
A Vim/Neovim plugin providing full vimwiki syntax support, implemented as a Rust-based language server (LSP).
Status: Phase 7 (semantic tokens) complete. The server now serves
semanticTokens/full+/rangewith customvimwiki*token types andlevel1..level6+centeredmodifiers. Navigation features and editor glue still pending.
See SPEC.md for the full project specification.
Implementation status
| Phase | Name | Status |
|---|---|---|
| 0 | Scaffolding | ✅ done |
| 1 | Core AST | ✅ done |
| 2 | Syntax Plugin Interface | ✅ done |
| 3 | Vimwiki Lexer | ✅ done |
| 4 | Vimwiki Parser | ✅ done |
| 5 | Renderer | ✅ done |
| 6 | LSP Foundation | ✅ done |
| 7 | Semantic Tokens | ✅ done |
| 8 | Navigation | ⏳ next |
| 9 | Editor Glue | ⏳ |
| 10 | CI/CD release pipeline | ⏳ |
Repository layout
nuwiki/
├── Cargo.toml workspace root
├── crates/
│ ├── nuwiki-core/ parser, AST, renderer (no editor deps)
│ ├── nuwiki-lsp/ LSP protocol bridge
│ └── nuwiki-ls/ binary that speaks LSP over stdio
├── plugin/ universal Vim/Neovim entry point
├── lua/nuwiki/ Neovim Lua glue
├── autoload/nuwiki/ Vim VimL glue
├── ftdetect/ filetype detection for .wiki
├── ftplugin/ per-buffer filetype settings
├── syntax/ static fallback highlighting
├── doc/ `:h nuwiki`
├── scripts/ build-time helpers
└── .gitea/workflows/ CI / release pipelines
Building
cargo build --workspace
cargo test --workspace
MSRV: Rust 1.83.
License
Dual-licensed under either of:
- Apache License, Version 2.0 (
LICENSE-APACHE) - MIT license (
LICENSE-MIT)
at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this work shall be dual licensed as above, without any additional terms or conditions.