Skip to content

Introduction

What is lazy.nvim?

lazy.nvim is a plugin manager for Neovim. It handles cloning, updating, and lazy-loading plugins from a set of declarative “specs” — Lua tables that say which plugin to install, what triggers it to load (a command, a keymap, a filetype, an event), and how to configure it once loaded.

What this is

A Neovim configuration written entirely from scratch on top of lazy.nvim — every option, keymap, and plugin spec here was written by hand, plugin by plugin. It is not the LazyVim distribution, and doesn’t depend on it. Distributions like LazyVim or kickstart.nvim ship pre-built, opinionated defaults (LSP presets via nvim-lspconfig’s setup functions, a formatter framework, a fixed plugin set); this config instead wires each piece directly, which means more to write, but nothing hidden behind a distribution’s abstractions.

What’s included, at a glance

  • Plugin managementlazy.nvim, bootstrapped automatically on first launch.
  • LSP — hand-rolled via vim.lsp.start(), not nvim-lspconfig’s presets. See Code Explanation.
  • Completionnvim-cmp with LSP, buffer, and path sources, plus LuaSnip for snippets.
  • Fuzzy finding — Telescope, for files, live grep, buffers, and help tags.
  • Syntaxnvim-treesitter, with highlighting and indent enabled for a fixed set of languages.
  • File explorernvim-tree.
  • Gitgitsigns.nvim for inline hunk signs/blame, neogit for a full Magit-style UI.
  • Two AI assistant integrations, side by sideclaudecode.nvim and codecompanion.nvim. See Code Explanation for why both exist.
  • Remote editingremote-sshfs.nvim, to browse and edit files on remote hosts over SSH/SSHFS.
  • Theming — Catppuccin (macchiato flavour, transparent background) as the single source of truth for colors, shared across the statusline, tabline, and dashboard.
  • UI polishnoice.nvim for a nicer cmdline/messages UI, lualine for the statusline, tabby.nvim for the tabline, alpha-nvim for a startup dashboard with a custom ASCII banner.

Why it exists

This is a daily-driver editor config, tuned to exactly the languages and workflows actually used day to day rather than a general-purpose “works for everyone” setup. Writing it by hand instead of adopting a distribution keeps every piece — what triggers a plugin to load, what an LSP server’s on_attach actually does, where a given keymap comes from — traceable to a single file, at the cost of having to wire up new functionality manually instead of getting it “for free.”

Last updated on