My Neovim Config: A Modular and Organized Approach

Neovim has become my go-to editor for its flexibility and performance. Over time, I have refined my configuration into a structured and modular setup that is easy to maintain and extend. In this article, I will walk through the organization of my Neovim configuration, explaining the purpose of each directory and how everything fits together.

Directory Structure

My Neovim configuration is organized as follows:

├── docs
├── ftplugin
├── images
├── lua
│   ├── configs
│   ├── constants
│   ├── icons
│   ├── keys
│   ├── plugins
│   │   ├── debug
│   │   ├── editor
│   │   ├── lang
│   │   ├── test
│   │   └── ui
│   ├── servers
│   ├── srandle
│   └── utils
└── snippets
    ├── base
    ├── js
    └── rust

docs/: Documentation

This directory contains markdown files explaining various aspects of my configuration, including plugin usage and setup explanations. Keeping documentation within the config itself makes it easier to maintain.

ftplugin/: Filetype-Specific Configurations

Here, I store configurations that apply only to specific file types. For example, I may define language-specific keybindings or custom behaviors for Python files that do not apply elsewhere.

images/: ASCII Art

I store ASCII art used in my Neovim startup screen or other parts of my configuration in this directory.

lua/configs/: Complex Plugin Configurations

Some plugins require configurations that are too intricate to fit within the Lazy plugin specification. I store such configurations in this directory to keep my plugin definitions clean and manageable.

lua/constants/: Global Constants

This directory houses constants used throughout my configuration. A key file here is languagepack.lua , which defines mappings between Mason , Mason LSP , lspconfig , linters , and formatters for different languages. This helps automate language tool setup.

Additionally, my pulled.lua file extracts properties from languagepack.lua into separate variables, making them easier to reference throughout my configuration.

lua/icons/: Icon Management

Any icons used throughout the configuration, such as those for status lines, diagnostic symbols, and UI enhancements, are stored here.

lua/keys/: Keybindings

Rather than scattering keybindings across various files, I centralize them here. This allows me to manage all my shortcuts in one place, making it easy to tweak or add new ones.

lua/plugins/: Plugin Management

This directory is divided into subdirectories to group plugins by category:

• debug/: Debugging tools such as DAP configurations.
• editor/: Enhancements to the core editing experience, like treesitter , fzf , nvim-cmp , and other plugins.
• lang/: Language-specific plugins, which are dynamically loaded based on my configured language pack.
• test/: Plugins related to testing frameworks.
• ui/: UI enhancements, such as status bars and file explorers.

lua/servers/: LSP Server Configurations

For LSP configurations that require more explicit setups beyond just calling lspconfig["server_name"].setup(), I define them here.

lua/srandle/: Personal Preferences & Lazy Entry Point

This directory holds my personal preferences and initial settings, such as vim.o.scrolloff = 999. It also contains the entry point for the Lazy package manager, keeping package management organized.

lua/utils/: Utility Functions

Various helper functions used throughout my configuration reside here, such as functions for managing keybindings, color schemes, and other commonly reused logic.

snippets/: VS Code-Style Snippets

This directory contains my custom snippets, used with nvim-cmp for autocompletion. I separate snippets into subdirectories like base/, js/, and rust/ to keep things structured.

Additional Configuration Files

Beyond the core directory structure, my setup includes:

• .stylelua.toml: Defines formatting rules for Lua.
• .luacheckrc: Configuration file for luacheck, a static analyzer for Lua.
• .editorconfig: Ensures consistent coding style.
• README.md: Documentation for the setup.
• .gitignore: Specifies files to exclude from version control.
• LICENSE.md: Defines licensing terms.

Conclusion

My Neovim configuration prioritizes modularity, making it easy to scale, debug, and tweak as needed. By structuring my config in this way, I can efficiently manage my plugins, keybindings, and settings without creating a tangled mess.

I hope this breakdown helps inspire your own Neovim setup. If you have any questions or suggestions, feel free to reach out!

Links heading-anchor

• https://github.com/stephansama/nvim
• https://dotfyle.com/stephansama/nvim