nvim-lua
feat(package manager): can i port this config to Lazy.nvim
as in "is it possible"? the answer is yes.
I am currently exploring lazy.nvim and may change the config to use it, but I have a few edge cases and questions i'm discussing with folke at the moment.
@tjdevries if you go through with it then a video about why and how would be interesting!
Is it stable enough for a beginner framework like kickstart? I'm new to vim/neovim. I've been trying every framework, modifying, breaking, writing my own versions, breaking them, studying dotfiles of well-known masters. I have been watching IT since it first landed in the repo. I'm dying to try it out, and plan to do so soon. Watching for Folke's framework too. But I've been subscribed to all posts from lazy repo and there are dozens every single day. Problems found and fixed. Regressions. Breaking releases. It's all getting fixed very quickly, but is it stable enough for a beginner framework?
I've used lazy.nvim (not commuted final changes to my dot files yet) and for beginner config, it works pretty well. You can clone folke's nvim dot files and remove plugins you don't use.
I understand kickstart's goal is simplicity and beginner friendliness, which results in a single short config file.
But a simple config (with lsp and completion plugins for, say cpp/rust and python) with different config files for different plugins would be great for people to build on. A single init.lua blows up very fast.
I don't know if it's stable enough yet -- that's why I'm waiting a bit before merging into this repo.
Yes, you can easily start to use other files after downloading this one. I do not want this to be a sprawling config that confuses people by it's breadth. It is supposed to kickstart people on their nvim journey, not be the final resting place of where they use nvim.
I understand kickstart's goal is simplicity and beginner friendliness, which results in a single short config file.
But a simple config (with lsp and completion plugins for, say cpp/rust and python) with different config files for different plugins would be great for people to build on. A single init.lua blows up very fast.
you can use this template by foke LazyVim
Just found out that packer_compiled.lua is not an lockfile as I thought initially (this was my bad because I never looked closely into it). But now that I know it's not supported in packer but supported by Lazy, this is huge vor beginners I would say, because it's just much easier to keep an working config in your repo and you can always go back if something break on an update.
This is the key feature for me and the reason why I will switch.
here i did a rudimentary version for this, plugins.lua and defaults.lua are not loading atm, so all customisation has to be done in the init.lua https://github.com/nvim-lua/kickstart.nvim/pull/169
Another aspect to this I think bears mentioning is that Packer is very straight forward to use. Add a single 'use' directive and you get a plugin installed.
I need to research further but it's not clear to me that lazy is as much of an easy base for people to build on.
Totally love this project - it has done exactly what it says on the tin and gave me a really nice foundaton on which to build.
I need to research further but it's not clear to me that lazy is as much of an easy base for people to build on.
The only thing to pay attention to when switching from Packer to Lazy is that the keywords used are different (for example: requires = for Packer becomes dependencies = in Lazy) which doesn't change anything for a beginner since he doesn't know any of them anyway. Then the configuration is actually slightly easier in Lazy (you don't even have to use use ^^ and it takes into account whatever you put in a .config/nvim/lua/plugins/ folder out of the box, for the rest it's very similar), it also has some other interesting features for beginners (not having to restart neovim after installing all the plugins for example).
Now it's still a relatively young project with quite a lot of issues to address and so, maybe it's not yet suitable for kickstart.nvim which is very understandable, I don't really know, but if you have the chance, it's definitely worth checking. :)
