This repository is a personal Neovim configuration rooted at ~/.config/nvim. It is built on top of LazyVim and lazy.nvim, with local behavior split across lua/config/*, lua/plugins/*, and a small set of helper modules.
- Treat this repo as an actively used personal editor config, not a generic starter template.
- Prefer narrow, surgical changes. Preserve existing behavior unless the task explicitly calls for a broader refactor.
- Assume the user cares about startup stability and interactive editing ergonomics more than novelty.
- Do not remove or rewrite environment-specific behavior unless requested. This config intentionally contains local machine and remote-session logic.
init.lua- Entry point.
- Loads
config.neovidewhenvim.g.neovideis set. - Loads
config.lazy, thenconfig.extras.
lua/config/- Core config modules and imperative setup.
- Use this for options, keymaps, autocmds, environment detection, host providers, dashboard wiring, folding behavior, diagnostics navigation, and similar editor-level behavior.
lua/plugins/- Lazy plugin specs and overrides.
- Files generally return plugin spec tables consumed by
require("lazy").setup(...).
lua/plugins/lsp/- Focused LSP overrides layered on top of LazyVim defaults.
lua/plugins/langs/- Language-specific plugin or tooling adjustments.
lua/utils/- Utility helpers, currently centered on floating-window debugging workflows.
after/ftplugin/- Filetype-specific overrides that should apply after startup.
lazy-lock.json- Plugin lockfile. Do not update it unless the task is explicitly about plugin version changes or a
:Lazyoperation that intentionally refreshes pins.
- Plugin lockfile. Do not update it unless the task is explicitly about plugin version changes or a
lua/plugins/*.disabled- Parked or experimental modules intentionally kept out of the active load path. Preserve this convention instead of deleting old work unless the user asks for cleanup.
- Put editor-wide settings in
lua/config/*, not in plugin spec files, unless the setting is truly plugin-local. - Put plugin declarations and plugin-specific
optsorconfiginlua/plugins/*. - For language-specific behavior, prefer
lua/plugins/langs/*orlua/plugins/lsp/*instead of growing a generic catch-all file. - When adding a new module, make sure it is actually wired into startup:
lua/config/*modules usually need arequire(...)frominit.luaorlua/config/extras.lua.lua/plugins/*modules must be imported throughlua/config/lazy.lua, either via{ import = "plugins" }or a specific{ import = "plugins.foo" }.
- Keep startup order in mind. Changes in
init.lua,lua/config/lazy.lua, andlua/config/extras.luaaffect load sequencing. lua/plugins/example.luais reference material, not an active config file. Do not copy large blocks from it blindly.- Prefer the existing module style:
- concise Lua modules
- direct
return { ... }for plugin specs - small comments only where behavior is non-obvious
- This config intentionally supports multiple environments:
miseis used when available to resolve Python and Ruby host providers inlua/config/host_providers.lua.- SSH sessions adjust clipboard behavior in
lua/config/remote_clipboards.lua. - Neovide-specific settings live in
lua/config/neovide.lua.
- Do not hardcode new machine-specific absolute paths unless the task requires it and there is no cleaner existing pattern.
- When changing provider or tool resolution logic, preserve the current fallback approach: prefer tool-managed paths when available, but tolerate environments where the tool is missing.
- Keep
README.mdaligned with the actual tree and startup flow when making structural or user-visible changes. Contributing.mdis legacy and generic; treat the codebase itself and the README as the more reliable source of truth.
scratch/,nvim.log,.luarc.json,.DS_Store, anddoc/tagsare local artifacts or ignored workspace files.- Do not commit scratch outputs or editor-generated noise.
After changing Lua config, prefer these checks:
- Formatting:
stylua --check .
- Startup sanity:
XDG_STATE_HOME=/tmp/codex-nvim-state XDG_CACHE_HOME=/tmp/codex-nvim-cache nvim --headless '+qa'
Notes:
- The temporary
XDG_STATE_HOMEandXDG_CACHE_HOMEoverrides avoid sandbox and local-state issues when running headless checks. - If a task intentionally changes plugin pins or plugin installation behavior, call that out explicitly and expect
lazy-lock.jsonor first-start plugin bootstrap effects.
- Prefer additive changes over broad rewrites.
- Preserve disabled modules unless cleanup is requested.
- Avoid unnecessary plugin churn. If LazyVim already provides a feature through an imported extra, prefer extending that setup over introducing overlapping plugins.
- When changing keymaps, options, or autocmds, check whether LazyVim already owns the default behavior and override only the delta needed here.
- If a change touches repo structure, startup wiring, or visible behavior, update the README in the same pass.