diff --git a/CHANGELOG.md b/CHANGELOG.md index d76947c..3e91b50 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -125,6 +125,43 @@ commit (`git tag -a vX.Y.Z -m vX.Y.Z`). ### Fixed +- **Neovim: focusing the file tree blanked the whole statusline.** `plugins/lualine-nvim.lua` set + both `disabled_filetypes = { statusline = { "NvimTree" } }` and `extensions = { "nvim-tree", … }`. + lualine evaluates `disabled_filetypes` and returns `nil` **before** it consults extensions + (`lualine.nvim/lua/lualine.lua:298-306`), so the `nvim-tree` extension was permanently unreachable + — and because `globalstatus = true` means one shared bar, that `nil` blanked the statusline for + _every_ window whenever the tree held focus. Dropped the disable and kept the extension. Verified: + with `ft=NvimTree` focused, `lualine.statusline()` returned `nil` before, renders 81 cells now. +- **Neovim: visual-mode git staging silently staged the entire hunk.** `gs` / `gr` + were mapped in `{ "n", "v" }` to bare `gs.stage_hunk` / `gs.reset_hunk`. `range` is the **first** + parameter of both (`gitsigns.nvim/lua/gitsigns/actions.lua:288`, `:376`) and a Lua keymap rhs is + invoked with no arguments, so `range` was always `nil` — partial-hunk staging, the only reason to + map visual mode, never happened. (Nothing reads the visual selection implicitly; only the + `:Gitsigns` command wrapper populates `range`, from command modifiers.) Normal and visual are now + separate mappings, with the visual pair passing `{ line("."), line("v") }` — upstream's documented + form — and bound to `x` rather than `v` so they do not also fire in select-mode. Verified end to + end in a real repo: staging lines 2-3 of a 3-line hunk staged exactly those two. +- **Neovim: the Node.js and python3 providers are disabled, clearing the config's only health + warning.** The node provider's sole consumers are remote plugins, but `config/lazy.lua` disables + the `rplugin` manifest loader, no installed plugin ships a manifest, and nothing references + `node_host` — so it was unreachable while still emitting a permanent `:checkhealth` WARNING. + python3 goes too: `vimade` is the only thing in the tree that mentions python, and it never + reaches that path here. `vimade#SetupRenderer()` (`vimade/autoload/vimade.vim:30-43`) + short-circuits to the Lua renderer whenever `renderer == 'auto'` and `supports_lua_renderer`, and + only the _else_ branch calls `SetupPython()`; `supports_lua_renderer` needs + `nvim_get_hl` + `nvim_win_set_hl_ns`, present since 0.11, and nvim-treesitter's main branch + already hard-requires 0.12 here — so the python fallback is unreachable. Confirmed at runtime: + `ACTIVE renderer = lua`, `vimade_python_setup = 0`, and `has('python3')` was never evaluated. + (nvim-dap-python spawns debugpy as an external DAP adapter — a subprocess, not this provider.) + Disabling both makes the cleanup portable: otherwise any fleet machine without `pynvim` keeps + emitting the same warning. `:checkhealth` is now **0 errors, 0 warnings** across every section. +- **Neovim: `gsn` (surround `update_n_lines`) never existed.** `plugins/mini-nvim.lua` passed + `update_n_lines = "gsn"` in mini.surround's `mappings`, but that is not a key in its schema + (`add`/`delete`/`find`/`find_left`/`highlight`/`replace`/`suffix_last`/`suffix_next`) and unknown + keys are accepted silently — `setup()` returned OK and no mapping was created, while every other + `gs*` map did exist. Mapped explicitly instead, as upstream's own docs prescribe + (`mini/surround.lua:909`), so the prefix the file advertises is real. + - **Neovim: SchemaStore catalogues never reached `jsonls` or `yamlls`.** Both resolved their schemas in `before_init` by re-binding `config.settings` with `vim.tbl_deep_extend`. The client binds `client.settings = config.settings` in `Client.create()` (runtime diff --git a/nvim/lua/gerrrt/config/providers.lua b/nvim/lua/gerrrt/config/providers.lua index 13a1f93..8263bce 100644 --- a/nvim/lua/gerrrt/config/providers.lua +++ b/nvim/lua/gerrrt/config/providers.lua @@ -9,8 +9,27 @@ vim.g.loaded_perl_provider = 0 -- almost never needed vim.g.loaded_ruby_provider = 0 -- enable only if some plugin actually needs ruby --- Node + Python providers are LEFT ENABLED on purpose — a few plugins use them, --- and the install notes get them healthy. If you later decide you don't need --- one, disable it the same way: --- vim.g.loaded_node_provider = 0 --- vim.g.loaded_python3_provider = 0 +-- Node provider: DISABLED, because nothing in this config can reach it. +-- • Its only consumers are remote plugins (node rplugins) — there is no `:node` command and no +-- vimscript/Lua entry point equivalent to py3eval. +-- • config/lazy.lua disables the `rplugin` runtime plugin (the remote-plugin MANIFEST loader), +-- so a remote plugin could not register even if one were installed. +-- • None of the installed plugins ships a remote-plugin manifest, and none references node_host. +-- Leaving it on bought nothing and cost a permanent `:checkhealth` WARNING ("Missing 'neovim' npm +-- package") — the ONLY warning in the whole config. Disabling is the documented, intended way to +-- clear that (vim.provider's own advice line says so), not a workaround. +vim.g.loaded_node_provider = 0 + +-- Python3 provider: DISABLED too. vimade is the ONLY thing in the tree that mentions python at all, +-- and it never reaches that path on any Neovim this config supports. vimade#SetupRenderer() +-- (vimade/autoload/vimade.vim:30-43) short-circuits to the Lua renderer whenever +-- `renderer == 'auto'` and `supports_lua_renderer`; only the ELSE branch calls SetupPython(). +-- supports_lua_renderer is `(nvim_get_hl or nvim__get_hl_defs) and nvim_win_set_hl_ns` (:112), all +-- present since 0.11 — and nvim-treesitter's main branch already hard-requires 0.12 here, so the +-- fallback is unreachable. Confirmed at runtime: renderer=auto, supports_lua_renderer=1, +-- ACTIVE renderer=lua, vimade_python_setup=0, and has_python3 was never even evaluated. +-- Nothing else references py3eval/pynvim (nvim-dap-python spawns debugpy as an external DAP +-- adapter — that is a subprocess, not this provider). +-- Disabling makes the provider cleanup PORTABLE: without it, any fleet machine lacking pynvim keeps +-- emitting the same :checkhealth warning we just removed for node. +vim.g.loaded_python3_provider = 0 diff --git a/nvim/lua/gerrrt/plugins/gitsigns-nvim.lua b/nvim/lua/gerrrt/plugins/gitsigns-nvim.lua index e9514f1..5986c5d 100644 --- a/nvim/lua/gerrrt/plugins/gitsigns-nvim.lua +++ b/nvim/lua/gerrrt/plugins/gitsigns-nvim.lua @@ -38,9 +38,25 @@ return { end end, "Prev git hunk") - -- Stage / reset (stage_hunk toggles: stages an unstaged hunk, unstages a staged one) - map({ "n", "v" }, "gs", gs.stage_hunk, "Stage / unstage hunk (toggle)") - map({ "n", "v" }, "gr", gs.reset_hunk, "Reset hunk") + -- Stage / reset (stage_hunk toggles: stages an unstaged hunk, unstages a staged one). + -- + -- NORMAL AND VISUAL ARE SEPARATE MAPPINGS, DELIBERATELY. `range` is the FIRST parameter + -- of both functions (gitsigns.nvim/lua/gitsigns/actions.lua:288 and :376), and a Lua + -- keymap rhs is invoked with NO arguments — so passing `gs.stage_hunk` bare in visual + -- mode left range = nil and staged the whole hunk under the cursor. The visual map was + -- decorative: partial-hunk staging, the only reason to map `v` at all, never happened. + -- (Nothing in gitsigns reads the visual selection implicitly; the `:Gitsigns` command + -- wrapper populates range from command modifiers, which a keymap does not go through.) + -- line(".") and line("v") are the two ends of the selection — this is upstream's own + -- documented form. `x` rather than `v` so it does not also fire in select-mode. + map("n", "gs", gs.stage_hunk, "Stage / unstage hunk (toggle)") + map("n", "gr", gs.reset_hunk, "Reset hunk") + map("x", "gs", function() + gs.stage_hunk({ vim.fn.line("."), vim.fn.line("v") }) + end, "Stage / unstage selected lines") + map("x", "gr", function() + gs.reset_hunk({ vim.fn.line("."), vim.fn.line("v") }) + end, "Reset selected lines") map("n", "gS", gs.stage_buffer, "Stage buffer") -- Inspect diff --git a/nvim/lua/gerrrt/plugins/lualine-nvim.lua b/nvim/lua/gerrrt/plugins/lualine-nvim.lua index f28e58d..65534df 100644 --- a/nvim/lua/gerrrt/plugins/lualine-nvim.lua +++ b/nvim/lua/gerrrt/plugins/lualine-nvim.lua @@ -179,7 +179,16 @@ return { -- (an empty string) so each half is one clean run instead of arrow-chevroned. section_separators = { left = "\u{e0b4}", right = "\u{e0b6}" }, -- e0b4 / e0b6 component_separators = "", - disabled_filetypes = { statusline = { "NvimTree" } }, + -- NO `disabled_filetypes = { statusline = { "NvimTree" } }` — it is actively harmful + -- with globalstatus. lualine checks disabled_filetypes and `return nil`s BEFORE it + -- consults extensions (lualine.nvim/lua/lualine.lua:298-306), so listing NvimTree + -- there did two bad things at once: it made the "nvim-tree" entry in `extensions` + -- (below) permanently unreachable, and — because globalstatus = true means ONE shared + -- bar — it blanked the statusline for EVERY window whenever the tree held focus. + -- Verified: with ft=NvimTree focused, lualine.statusline() returned nil. + -- The extension is the thing that renders a sensible bar for the tree, so keep that + -- and drop the disable. If you ever do want the bar to vanish over the tree, remove + -- "nvim-tree" from `extensions` too — but do not set both. }, sections = { lualine_a = { diff --git a/nvim/lua/gerrrt/plugins/mini-nvim.lua b/nvim/lua/gerrrt/plugins/mini-nvim.lua index 2903995..3dd4b4c 100644 --- a/nvim/lua/gerrrt/plugins/mini-nvim.lua +++ b/nvim/lua/gerrrt/plugins/mini-nvim.lua @@ -70,9 +70,20 @@ return { find = "gsf", -- find surround to the right find_left = "gsF", -- find surround to the left highlight = "gsh", -- highlight surround - update_n_lines = "gsn", -- update n_lines used for search + -- NO `update_n_lines = "gsn"` here: mini.surround has no such `mappings` key. Its + -- schema is add/delete/find/find_left/highlight/replace/suffix_last/suffix_next, and + -- unknown keys are accepted SILENTLY (setup returns ok, no warning) — so `gsn` was + -- never created. Verified: every other gs* map exists at runtime, gsn did not. + -- Upstream's own docs (mini/surround.lua:909) say to map it yourself — see below. }, }) + -- `gsn` — the mapping the table above could not create. MiniSurround.update_n_lines() prompts + -- for a new `n_lines` (how far surround searches); keeping it on gsn honours the prefix this + -- config advertises. No conflict: the generated "next/last" variants are gsn/l + -- (gsdn, gsfn, …), none of which is a prefix of gsn. + vim.keymap.set("n", "gsn", function() + require("mini.surround").update_n_lines() + end, { desc = "Update surround n_lines" }) require("mini.cursorword").setup({}) require("mini.pairs").setup({}) require("mini.trailspace").setup({})