Nvim 0.12 update - #42
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis pull request updates multiple Neovim configuration files, primarily migrating keymap option names from Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
lua/plugins/harpoon.lua (1)
67-79:⚠️ Potential issue | 🔴 Critical
vim.keymap.setexpectsbuffer, notbuf— keymaps will be global instead of buffer-local.The native Neovim
vim.keymap.setAPI usesbuffer(notbuf) to scope keymaps to a specific buffer. Using{ buf = cx.bufnr }will cause this option to be silently ignored, making<C-v>and<C-x>apply globally rather than only in the Harpoon menu window.Fix
vim.keymap.set( "n", "<C-v>", function() harpoon.ui:select_menu_item({ vsplit = true }) end, - { buf = cx.bufnr } + { buffer = cx.bufnr } ) vim.keymap.set( "n", "<C-x>", function() harpoon.ui:select_menu_item({ split = true }) end, - { buf = cx.bufnr } + { buffer = cx.bufnr } )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lua/plugins/harpoon.lua` around lines 67 - 79, The mappings for harpoon.ui:select_menu_item are being set with vim.keymap.set using the wrong option key — change the option from { buf = cx.bufnr } to { buffer = cx.bufnr } for both mappings so they become buffer-local; update the two calls to vim.keymap.set that reference cx.bufnr (the <C-v> and <C-x> mappings) to use the buffer option instead of buf.lua/nikero/keymaps.lua (1)
60-68:⚠️ Potential issue | 🔴 CriticalNeovim API returns
buffer, notbuf— buffer info will always be nil.The
vim.api.keyset.get_keymaptype (returned bynvim_get_keymapandnvim_buf_get_keymap) contains abufferfield, notbuf. Readingkeymap.bufwill always benil, so buffer-local keymaps won't be correctly identified when loaded from Neovim's keymap API.🐛 Proposed fix
opts = { desc = keymap.desc, - buf = keymap.buf, + buf = keymap.buffer, silent = keymap.silent == 1 and true or false, expr = keymap.expr == 1 and true or false, noremap = keymap.noremap == 1 and true or false, script = keymap.script == 1 and true or false, },What fields does Neovim's nvim_get_keymap API return for buffer-local keymaps?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lua/nikero/keymaps.lua` around lines 60 - 68, The code is reading keymap.buf which is always nil because Neovim's keymap API uses the field name buffer; update the keymap options assembly (where opts is built using keymap.desc, keymap.buf, etc.) to read keymap.buffer instead of keymap.buf so buffer-local maps are preserved, keeping the existing truthy checks (e.g., keymap.buffer == 1 and true or false) and leaving other fields (desc, silent, expr, noremap, script) unchanged.lua/filetypes.lua (1)
115-120:⚠️ Potential issue | 🔴 CriticalRemove unsupported
bufoption fromSnacks.keymap.set.
Snacks.keymap.setdoes not accept abufoption for buffer-local keymaps. According to the official Snacks.nvim API, this method only supportsft(filetype) orlsp(LSP client filter) for scope. Thebufparameter is silently ignored, so the keymap will apply globally rather than to the specific buffer. Use either filetype-specific scoping withftor remove the buffer option and manage the keymap lifecycle separately if buffer-local binding is needed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lua/filetypes.lua` around lines 115 - 120, The keymap is being created with Snacks.keymap.set using a unsupported buf option which is ignored, causing the "q" mapping to be global; replace the buffer-scoped call by either using Snacks.keymap.set with the ft or lsp scoping supported by Snacks (e.g., pass ft = <filetype> to scope to that filetype) or remove the buf option and set a true buffer-local mapping via vim.api.nvim_buf_set_keymap / vim.keymap.set with the specific args.buf as the target; ensure the mapped callback still calls Snacks.bufdelete.delete({ buf = args.buf, force = true }) and that the mapping is created inside the vim.schedule block so it binds for the intended buffer only.
🧹 Nitpick comments (1)
lua/keymaps.lua (1)
167-172: Description says "refresh" but action is now "enable".The keymap description is
"LSP CodeLens refresh"but the callback now callsvim.lsp.codelens.enable(true). While enabling does trigger a refresh, the semantic intent differs. Consider updating the description for clarity.Also note this enables CodeLens globally (no buffer argument), whereas the
on_attachinlua/plugins/language/support.luaenables per-buffer with{ bufnr = buffer }.♻️ Suggested description update
{ "n", "<leader>ll", function() vim.lsp.codelens.enable(true) end, - { desc = "LSP CodeLens refresh", lsp = { method = "textDocument/codeLens" } }, + { desc = "LSP CodeLens enable", lsp = { method = "textDocument/codeLens" } }, },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lua/keymaps.lua` around lines 167 - 172, The keymap currently calls vim.lsp.codelens.enable(true) but the description says "LSP CodeLens refresh" and the enable call affects global state (no bufnr) unlike the per-buffer enabling in on_attach (lua/plugins/language/support.lua); either update the keymap description to accurately say "LSP CodeLens enable" (or "Enable LSP CodeLens (global)") or change the callback to perform a refresh/ per-buffer enable consistent with on_attach (e.g., call vim.lsp.codelens.refresh() for a refresh action, or call vim.lsp.codelens.enable({ bufnr = <buffer> }) if you can access the buffer), and update the desc and lsp metadata accordingly to match the chosen behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@lua/filetypes.lua`:
- Around line 115-120: The keymap is being created with Snacks.keymap.set using
a unsupported buf option which is ignored, causing the "q" mapping to be global;
replace the buffer-scoped call by either using Snacks.keymap.set with the ft or
lsp scoping supported by Snacks (e.g., pass ft = <filetype> to scope to that
filetype) or remove the buf option and set a true buffer-local mapping via
vim.api.nvim_buf_set_keymap / vim.keymap.set with the specific args.buf as the
target; ensure the mapped callback still calls Snacks.bufdelete.delete({ buf =
args.buf, force = true }) and that the mapping is created inside the
vim.schedule block so it binds for the intended buffer only.
In `@lua/nikero/keymaps.lua`:
- Around line 60-68: The code is reading keymap.buf which is always nil because
Neovim's keymap API uses the field name buffer; update the keymap options
assembly (where opts is built using keymap.desc, keymap.buf, etc.) to read
keymap.buffer instead of keymap.buf so buffer-local maps are preserved, keeping
the existing truthy checks (e.g., keymap.buffer == 1 and true or false) and
leaving other fields (desc, silent, expr, noremap, script) unchanged.
In `@lua/plugins/harpoon.lua`:
- Around line 67-79: The mappings for harpoon.ui:select_menu_item are being set
with vim.keymap.set using the wrong option key — change the option from { buf =
cx.bufnr } to { buffer = cx.bufnr } for both mappings so they become
buffer-local; update the two calls to vim.keymap.set that reference cx.bufnr
(the <C-v> and <C-x> mappings) to use the buffer option instead of buf.
---
Nitpick comments:
In `@lua/keymaps.lua`:
- Around line 167-172: The keymap currently calls vim.lsp.codelens.enable(true)
but the description says "LSP CodeLens refresh" and the enable call affects
global state (no bufnr) unlike the per-buffer enabling in on_attach
(lua/plugins/language/support.lua); either update the keymap description to
accurately say "LSP CodeLens enable" (or "Enable LSP CodeLens (global)") or
change the callback to perform a refresh/ per-buffer enable consistent with
on_attach (e.g., call vim.lsp.codelens.refresh() for a refresh action, or call
vim.lsp.codelens.enable({ bufnr = <buffer> }) if you can access the buffer), and
update the desc and lsp metadata accordingly to match the chosen behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 141d0b1a-8a1c-42f7-89b3-052e9c1d875e
📒 Files selected for processing (11)
lsp/tsgo.lualua/filetypes.lualua/keymaps.lualua/nikero/keymaps.lualua/options.lualua/plugins/git.lualua/plugins/harpoon.lualua/plugins/language/support.lualua/plugins/language/typescript.lualua/plugins/syntax.lualua/plugins/ui.lua
💤 Files with no reviewable changes (1)
- lua/plugins/ui.lua
1 participant
This pull request introduces several improvements and refactorings across the codebase, focusing on standardizing buffer-related option naming, improving LSP handler usage, and updating diagnostics and plugin integrations for better maintainability and clarity. The most significant changes are grouped below.
Standardization of Buffer Option Naming
bufferoption withbufin keymap and plugin configurations for consistency, affecting files such aslua/filetypes.lua,lua/nikero/keymaps.lua,lua/plugins/git.lua, andlua/plugins/harpoon.lua. [1] [2] [3] [4] [5] [6] [7]LSP Handler and Diagnostic Improvements
vim.lsp.handlersinstead of deprecated or direct handler calls in TypeScript and Go plugin configurations, improving future compatibility and code clarity. [1] [2] [3]vim.lsp.codelens.enable(true)instead ofrefresh()for better alignment with upstream LSP API changes, and updated related plugin attachment logic. [1] [2]Diagnostic and Treesitter Enhancements
on_jumpcallback that opens a floating window at the cursor for improved user experience.Plugin and UI Adjustments
vim.lsp.util.stylize_markdownin the UI plugin, possibly to restore default behavior or fix a bug.These changes collectively enhance code consistency, maintainability, and compatibility with evolving Neovim APIs.