The Plugin That Replaced Eight Others
One config file, one plugin, and a feature I'd had switched off for months on an assumption.
At some point my Neovim config had a picker plugin, a dashboard plugin, a notification plugin, a terminal plugin, a file explorer plugin, a zen-mode plugin, and a scratch-buffer plugin, each with its own config file, its own keymap conventions, its own way of doing borders and window styling. Snacks.nvim replaced all of it. I swapped it in over a weekend and deleted six files.
Fewer files is nice but it's not a story. The interesting part is a comment I left in my own config a while back that I finally circled back to:
-- Was disabled on the assumption magick wasn't installed; :checkhealth
-- reports ImageMagick 7.1.2 present and Ghostty detected as a supported
-- terminal (it speaks the kitty graphics protocol), so both requirements
-- are actually met.
image = { enabled = true },
I'd turned off inline image rendering in markdown buffers months earlier because I thought I didn't have ImageMagick installed, and never actually checked. It sat disabled through however many :Lazy sync runs, until I ran :checkhealth for an unrelated reason and saw ImageMagick sitting there, and my terminal already speaking the right graphics protocol. The feature had been available the entire time I was telling myself it wasn't.
The rest of the plugin follows the same shape everywhere: check first, enable conditionally, don't assume. The lazygit integration does the same thing but out loud instead of silently:
function()
if vim.fn.executable("lazygit") == 1 then
Snacks.lazygit()
else
vim.notify("lazygit not installed. Run: brew install lazygit", vim.log.levels.WARN)
end
end,
Instead of a "command not found" from a shell-out gone wrong, missing lazygit just tells you what to do about it. Small thing, but it's the difference between a plugin that fails politely and one that fails like a stack trace.
None of this needed eight separate plugins to begin with, which is the lesson. A stack of single-purpose plugins feels more modular until you're maintaining eight sets of keymap conventions and eight border styles that don't match. One plugin that does all of it consistently, written by people who use it themselves, ends up being less config to reason about even though its own opts table is longer than any plugin's used to be. I didn't consolidate for the file count. I consolidated because the eight-plugin version kept breaking in ways a single well-maintained one doesn't.

