NixOS keeps glibc in the store, so a generic `-gnu` release binary cannot
find its dynamic loader. The old detection missed this twice over: `ldd
--version` reports plain GNU libc there, and `/lib64/ld-linux-x86-64.so.2`
does exist — as a stub that only prints an error and exits 127. The
installer downloaded the gnu asset, `executable()` returned 1, and the
binary could never start.
Detect non-FHS distributions (`/etc/NIXOS`, `ID=nixos`/`ID=guix` in
os-release) and pick the statically linked musl asset there. Turn the
single target triple into an ordered candidate list so glibc hosts fall
back to musl too, and verify the staged binary actually execs — exit 126
or 127 means the kernel or loader refused it — before it lands in `bin/`.
Applied to both installers (Lua and the Vim build hook, which the shell
test harnesses source). Adds `g:nuwiki_ls_target` to force a triple.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qPCSWXxATFvjEpVxQMhG9
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 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>
P5 + P6 resolved (SPEC §11): Neovim 0.11+ and Vim 9.1+.
Universal Vim entry:
- plugin/nuwiki.vim dispatches Vim vs Neovim. Neovim path waits for
the user's `require('nuwiki').setup()` call; Vim path starts the
LSP client on `FileType vimwiki` and exposes `:NuwikiInstall`.
- ftdetect/nuwiki.vim associates `*.wiki` with the `vimwiki` filetype.
- ftplugin/nuwiki.vim sets commentstring + comments + formatoptions +
suffixesadd + iskeyword, with a clean `b:undo_ftplugin`.
- syntax/nuwiki.vim ships default `@vimwiki*` highlight links for the
semantic-token legend (with `level1..6` + `centered` modifiers),
plus a minimal regex fallback so static highlighting works before
the LSP attaches.
Lua glue (Neovim 0.11+):
- init.lua exposes setup() / install() / health() — wiring only per
SPEC §6.2.
- config.lua holds the §7.5 schema (wiki_root / file_extension /
syntax / log_level) and a tbl_deep_extend apply().
- lsp.lua registers via `vim.lsp.config{} + vim.lsp.enable` on 0.11+;
falls back to a FileType autocmd calling `vim.lsp.start` on older
builds. Root dir walks up for `.git` / `.nuwiki`, then uses
wiki_root.
- install.lua does target-triple detection (Linux gnu/musl x x86_64/
aarch64, macOS arm/x86, Windows), curl+tar download from the
release URL, cp/chmod into bin/, with a cargo fallback. Honours
`g:nuwiki_build_from_source`.
- health.lua implements `:checkhealth nuwiki` per §7.6.
VimL glue (Vim 9.1+):
- autoload/nuwiki/lsp.vim follows §7.4 preference order:
vim-lsp (calls `lsp#register_server`) → coc.nvim (prints the
coc-settings.json snippet) → error.
- scripts/download_bin.vim mirrors the Lua installer for Dein /
vim-plug build hooks — same target triples, same download →
fallback → cargo build chain.
Help: doc/nuwiki.txt with tags for install (lazy.nvim / vim-plug /
Dein), config options, health, LSP feature list, `:NuwikiInstall`.
Rust workspace unchanged this phase; 172 tests still green locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gffranco
gffranco