fix(nvim): statusline blanking, visual git staging, node provider, gsn

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.** `<leader>gs` / `<leader>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

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

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" }, "<leader>gs", gs.stage_hunk, "Stage / unstage hunk (toggle)")
-			map({ "n", "v" }, "<leader>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", "<leader>gs", gs.stage_hunk, "Stage / unstage hunk (toggle)")
+			map("n", "<leader>gr", gs.reset_hunk, "Reset hunk")
+			map("x", "<leader>gs", function()
+				gs.stage_hunk({ vim.fn.line("."), vim.fn.line("v") })
+			end, "Stage / unstage selected lines")
+			map("x", "<leader>gr", function()
+				gs.reset_hunk({ vim.fn.line("."), vim.fn.line("v") })
+			end, "Reset selected lines")
 			map("n", "<leader>gS", gs.stage_buffer, "Stage buffer")
 
 			-- Inspect

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 = {

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 gs<action>n/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({})