From c5814a3e2134722ae67ff7be83d9b2619efdf3bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gabriel=20Fr=C3=B3es=20Franco?= Date: Sun, 31 May 2026 09:02:52 -0300 Subject: [PATCH] docs(gap): log link-follow new-tab regression MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pressing on a link now opens a new tab and switches to it instead of reusing the current window (reported on Vim 9.x + Dein). Records the investigation so far — the path is unchanged by recent P1 work and both client jump paths open same-window by default — and the env gotchas (stale dein copy, double rtp) to rule out before treating it as a code bug. Co-Authored-By: Claude Opus 4.7 --- development/vimwiki-gap.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/development/vimwiki-gap.md b/development/vimwiki-gap.md index b63f6da..d508293 100644 --- a/development/vimwiki-gap.md +++ b/development/vimwiki-gap.md @@ -42,6 +42,32 @@ fix site. reaches the whole-buffer sweep that `gL` previously held (the only prior entry point). Normal-mode only. +## Regressions (reported by users — verify, then fix) + +- [ ] **`` link-follow opens a new tab instead of reusing the current + window** — pressing `` on a link used to open the target in the *same* + tab/window the user was browsing in (upstream behavior). It now opens a + **new tab and switches to it**. Reported on Vim 9.x + Dein. + _Investigation so far:_ the nuwiki `` path is **unchanged** by the recent + P1 #1/#2/#3 work — `git blame` shows the `` map (`ftplugin/vimwiki.vim` + Vim branch `:206`, Neovim branch `lua/nuwiki/keymaps.lua:161`) and the + `follow_link_or_create` → jump-definition chain were not touched; only + `` was repointed to `follow_link_drop()` in `f65d861`. Both client + jump paths open in the current window by default + (`vim.lsp.buf.definition()` with no opts; Vim `s:jump_definition()` → + `LspDefinition`, `autoload/nuwiki/commands.vim:73`), so the new-tab behavior + is **not** coming from nuwiki's own placement logic as written. + _Rule out first (env, per memory):_ a **stale dein copy** of the plugin + (`bin/nuwiki-ls` + copied ftplugin) and a **double `rtp` entry** where the + upstream vimwiki bundle is still loaded alongside nuwiki — either can shadow + the `` map or pull in upstream/`LspDefinition --tab`-style behavior. + Recache dein + rebuild + restart LSP and confirm only nuwiki's ftplugin is + active before treating this as a nuwiki code bug. + _Suspected sites if it reproduces clean:_ vim-lsp's definition-open default + (Vim) and the `vim.lsp.buf.definition()` handler (Neovim) — pin which `` + press (bare-word wrap vs. existing-link follow) triggers the tab and whether + the server's definition response shape steers placement. + ## P2 — Moderate (real users hit these) - [ ] **`wt` collision** — upstream = today-in-new-tab; nuwiki =