docs(known-issues): make it the single source of truth
CI / cargo fmt --check (push) Successful in 17s
CI / cargo clippy (push) Successful in 30s
CI / cargo test (push) Successful in 40s
CI / editor keymaps (push) Successful in 1m25s

Promote known-issues.md to the authoritative divergence reference ahead
of retiring development/vimwiki-gap.md:
- drop the pointer into vimwiki-gap.md so the file stands alone
- reframe the intro as the single source of truth
- add an "Internal deferrals (non-parity)" section capturing the
  cold-path optimizations (RSS render_entry_body disk read,
  push_level_edit_for_line offset scan, diary neighbor scan) that
  otherwise only lived in the gap doc, so nothing is lost on deletion

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-03 14:27:00 +00:00
parent 38fed6dd9e
commit 255e24d1e0
+22 -4
View File
@@ -5,10 +5,9 @@ not a fork of the original VimL plugin. It targets behavioral parity with
vimwiki, but a handful of upstream options and behaviors are implemented vimwiki, but a handful of upstream options and behaviors are implemented
differently — or intentionally not at all — because of that architecture. differently — or intentionally not at all — because of that architecture.
This page lists what to expect if you're coming from vimwiki. Everything here This page is the single source of truth for how nuwiki differs from vimwiki.
is either a deliberate design choice or a tracked future task; none of it is an Everything here is either a deliberate design choice or a tracked future task;
accidental bug. For the detailed, per-option parity log (with code references none of it is an accidental bug.
and test names), see [`development/vimwiki-gap.md`](development/vimwiki-gap.md).
If you hit a behavior that *isn't* listed here and doesn't match vimwiki, please If you hit a behavior that *isn't* listed here and doesn't match vimwiki, please
file it — that's a real bug. file it — that's a real bug.
@@ -108,6 +107,25 @@ self-contained. You can set any of these explicitly to match upstream exactly.
--- ---
## Internal deferrals (non-parity)
These are not vimwiki differences — they're known low-priority optimizations on
cold code paths, recorded so they aren't rediscovered as "bugs." All are
correct as-is; the deferral is a deliberate risk/reward call.
- **RSS `render_entry_body` reads from disk.** It re-reads and re-parses each
diary entry from disk rather than reusing an open buffer. This is the *correct*
source of truth for an export artifact — switching to unsaved buffer text would
change semantics, not just performance.
- **`push_level_edit_for_line` scans from offset 0.** The list-level change
(`gl`/`gL`) computes each line's start offset by scanning from the document
start. It's an interactive single-keypress path over small inputs, and the
offset-arithmetic rewrite carries more regression risk than the saved time is
worth.
- **Diary next/prev neighbor scan.** `:VimwikiDiaryNextDay` / `PrevDay` rebuild
and sort the entry list to find one neighbor. Same reasoning — cold path,
small input.
## Notes ## Notes
- **Third-party plugin compatibility.** A shim at `autoload/vimwiki/vars.vim` - **Third-party plugin compatibility.** A shim at `autoload/vimwiki/vars.vim`