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>
68 lines
2.1 KiB
Markdown
68 lines
2.1 KiB
Markdown
# 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` + `/range` with custom `vimwiki*` token types and
|
|
> `level1`..`level6` + `centered` modifiers. Navigation features and
|
|
> editor glue still pending.
|
|
|
|
See [`SPEC.md`](./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
|
|
|
|
```sh
|
|
cargo build --workspace
|
|
cargo test --workspace
|
|
```
|
|
|
|
MSRV: Rust 1.83.
|
|
|
|
## License
|
|
|
|
Dual-licensed under either of:
|
|
|
|
- Apache License, Version 2.0 ([`LICENSE-APACHE`](./LICENSE-APACHE))
|
|
- MIT license ([`LICENSE-MIT`](./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.
|