[audit] gr buffer-local keymap blocks Neovim 0.11+ built-in grr/grn/gra/gri LSP keymaps #114

What

lua/config/plugin_config.lua (line 113) sets a buffer-local keymap in LspAttach:

vim.keymap.set("n", "gr", vim.lsp.buf.references, opts)

Since Neovim 0.11, Neovim ships these default LSP keymaps (set automatically on LspAttach):

Where

lua/config/plugin_config.lua, line 113.

Why it matters

Neovim's keymap timeout logic: when gr is mapped, pressing g then r executes the binding immediately — the editor does not wait to see if grn, gra, grr, or gri follow. All four built-in gr* keymaps become unreachable. Rename, code action, and go-to-implementation have no working keybinding as a result (unless they were re-bound elsewhere — they weren't in this config).

This is tracked separately from issue #38 (Expand LSP keymaps), which proposes adding hover/rename/code-action bindings. Resolving this conflict is a prerequisite for that work: even if you add grn/gra/gri manually, they will remain shadowed until gr is dealt with.

Recommended action

Two viable paths — choose based on preference:

Option A — drop gr, rely on built-ins (recommended):
Remove the gr → references mapping entirely. The built-in grr covers references, and grn/gra/gri fill out the LSP keymap surface for free.

-- delete this line:
vim.keymap.set("n", "gr", vim.lsp.buf.references, opts)

Option B — keep gr but remap built-ins explicitly:
If one-key gr for references is preferred, explicitly bind grn/gra/gri to different keys (e.g. <leader>rn, <leader>ca) so they aren't lost.

vim.keymap.set("n", "gr",         vim.lsp.buf.references,      opts)
vim.keymap.set("n", "<leader>rn", vim.lsp.buf.rename,           opts)
vim.keymap.set("n", "<leader>ca", vim.lsp.buf.code_action,      opts)
vim.keymap.set("n", "<leader>gi", vim.lsp.buf.implementation,   opts)

The choice affects muscle memory and is up to the user — hence this is an issue rather than a PR.