Neovim
Editor configuration, plugins and key bindings.
Topics & articlesContents
1 topicsArticles
- Neovim Plugin Specifications and Key Management
- Neovim editing actions, registers and project navigation
- Neovim: Language Services, Completion, and Formatting
- A Neovim project exercise fixing a boundary error
- Neovim: Chinese Input, Remote Clipboard and Window Collaboration
- Neovim versions, upgrades and fault isolation
Neovim provides editing, windows, terminals and language-client facilities. LazyVim packages plugins, bindings and configuration conventions into a distribution. It reduces initial assembly but does not remove the need to understand file types, project roots, external tools and versions.
This series assumes terminal familiarity. If Vim editing is new, complete :Tutor first: insert text, return to normal mode, save and exit.
Reading path
| Stage | Chapter | Outcome |
|---|---|---|
| 1 | This introduction | Identify loaded configuration and run health checks |
| 2 | Editing and navigation | Use text objects, registers, windows and quickfix |
| 3 | Language tools | Distinguish LSP, completion, parsing and formatting |
| 4 | A Rust change | Reproduce a failing test, repair and review |
| 5 | Plugins and mappings | Make focused overrides and inspect key origins |
| 6 | Remote work and input | Configure input methods, OSC52 and Zellij navigation |
| 7 | Maintenance | Pin versions, isolate faults and restore working state |
Use individual chapters for an existing setup. New users should complete the project task before adding optional plugins.
Check prerequisites
Compare the installed version and external dependencies with LazyVim's current requirements. Fonts affect icons; compilers may build parsers or native plugins; SDKs depend on the project.
Configuration conventions here reference LazyVim 16. The maintenance machine uses a Neovim 0.13 development build, which is not a requirement for readers. Record exact versions when troubleshooting API differences.
Try an isolated configuration
On Linux/macOS, use NVIM_APPNAME to separate a learning setup. The destination must not already exist:
Launch it:
NVIM_APPNAME=nvim-lab
First startup downloads plugins and needs network access and build tools. Use the same application name each time; plain nvim still uses the normal configuration. Do not delete the existing setup to test a configuration idea. Installation
Windows paths differ. Query actual locations inside Neovim:
:lua print(vim.fn.stdpath("config"))
:lua print(vim.fn.stdpath("data"))
The first is configuration; the second normally contains plugin data.
Configuration responsibilities
nvim-lab/
├── init.lua
├── lazyvim.json
├── lazy-lock.json
└── lua/
├── config/
│ ├── lazy.lua
│ ├── options.lua
│ ├── keymaps.lua
│ └── autocmds.lua
└── plugins/
└── editing.lua
init.lua enters configuration; lazy.lua initialises plugin management; options.lua, keymaps.lua and autocmds.lua hold options, mappings and event responses. Files under lua/plugins/ return plugin specifications. lazyvim.json records extras and lazy-lock.json pins plugin commits.
Use :LazyExtras to inspect and enable language support, then complete installation and restart as instructed. Optional integrations and external SDKs are not guaranteed to be installed by selecting an extra.
Verify the first startup
Run :LazyHealth, then inspect task-relevant :checkhealth results. An unrelated optional provider need not block editing, but missing tools for the selected language do matter.
Place basic options in lua/config/options.lua:
vim.opt.number = true
vim.opt.relativenumber = true
vim.g.autoformat = false
Disabling automatic formatting helps make changes visible while learning. Restore project-appropriate behaviour later; see language tools.
Preparation is complete when you can open and save files, identify the configuration directory and explain relevant health-check failures. Continue with editing and navigation, then verify everything through the project exercise.