UPDATE: Since I wrote this I moved to kickstart. Lazyvim does too many things and I prefer having more control. With kickstart I totally control and understand how I am running my neovim instances.
I recently saw this youtube video where the author transitioned from a custom made Neovim configuration to lazyvim. I have always written from scratch my Neovim config but now I am going to use Lazyvim (LV). Why?
My Neovim setup
Lazyvim comes with a very sensible (IMMO) layout and structure for Neovim plugins. If you are familiar with Lua and Neovim, adjusting the config to your needs is easy. But most importantly, because Lazyvim comes with a sensible list of plugins, you can see functionality that you wouldn’t see otherwise.
Another thing I appreciate with Lazyvim is that, for the most part, the keymaps make sense. Mapping keys to functionality is not easy. Naming is hard. LV uses the which-key plugin which allows you to quickly find out what key mappings are available. I believe the LV authors did a much better job finding sensible keymaps than I did.
I am not suggesting you jump into Lazyvim if you are starting with Neovim. I believe you will get overwhelmed. You need to have worked with a Neovim setup that you have created youself so you understand how it works and have expertise with the most used plugins: LSP, treesitter, telescope, etc… You may be tempted to ignore this advice but I’d advice against that. When you fire Neovim+LV, you may feel that tons of functionality but it will be painful when you start making tweaks to your config. That’s what I think.
For users that are moving from their custom configs to LV, one of the challenges is to rewire your muscle memory for the keymaps. I have a couple of comments here. Be patience, let your brain get use to this new environment. Use the which-key functionality to learn why they mapped the keys the way they did. That will help your brain rewire the new key mapping faster. I had a few key mappings that I wanted to either change or add. If you have to change a key map, disable it first in the plugin and then add it in your custom config files. Like in the video above, I like to keep configuration files that are related to a particular concept: like ui, keymaps, etc…
Also, the UI dumps a lot of data at you. The placement of the different visual components will be probably substantially different to your old setup. You will have to get use to it.
Drio out.