Closed stroiman closed 2 months ago
tldr: When configuring neovim, it is essential to me that I can reload my configuration without having to exit and restart neovim
Neovim (or even Vim) is not designed for this and therefore (just like lazy.nvim) will not be supported here.
Any package manager that claims to support this is misleading and will only approximate this feature at best.
Neovim (or even Vim) is not designed for this and therefore (just like lazy.nvim) will not be supported here.
If you don't plan to support this, that's fine, and I respect that.
But it's not correct that vim is not designed for this. That is one of the primary reasons for autogroups, from :help augroup
Example: :augroup uncompress : au! : au BufEnter *.gz %!gunzip :augroup END
This prevents having the autocommands defined twice (e.g., after sourcing the vimrc file again).
I would never expect everything to be perfect, e.g. if an already loaded plugin is removed; it could still exist and cause problems because of e.g. already configured autocommands. But I could add plugins on the fly with VimPlug, packer, and to a large extend that seems to be the case with pckr (from the limited experience I've had so far) - as long as I don't make any mistakes.
There are a lot more types of state than just augroups, especially in Neovim.
You may not require to be perfect, but when you need to support a feature generally for many kinds of users there needs to be a threshold of feasibility that it can be implemented robustly.
Background
tldr: When configuring neovim, it is essential to me that I can reload my configuration without having to exit and restart neovim
I've been a long time vim user, and the ability to re-source the vimrc file seems to be common for old vimscript hackers (it's one of the first tips of Learn Vimscript the Hard Way, setup keyboard shortcuts to quickly edit, and source the vimrc file.
Right now, I'm building a new neovim config from scratch. Previously, I used packer, which did support this, so I decided to go with pckr for now.
(I looked at lazy.nvim, and it specifically does not support this, which is mind boggling to me. I might be able to get it to work with user events, but, arg.)
What I specifically like about pckr over other managers I've used
One thing I really like about pckr is the ability to progressively add plugins; which allows me to moduralise the configuration; while still keeping the plugin specification and the plugin initialization colocated in code.
The Problem: Invalid plugin names are remembered - forcing a restart
tldr; When I have added a bad plugin name, I'm forced to quitting neovim. Re-sourcing the config results in an error after I fixed it.
My specific problem I run into is when I have made a mistake, and added an invalid plugin name. pckr remembers this, and wants to try to install it on every reload. I need to restart neovim to clear the state (as far as I can tell)
E.g. I wanted to add catppuccin color scheme, so I added this
And sourced my config, and get an error, because the plugin spec was wrong. I fixed the config,
When I re-source my config, packer still remembers that the bad
"catppuccin"
plugin is not installed, and tries to do that; resulting in an error. I'm left with no alternative but to quit neovim.As far as I can tell, this information is stored in a local in
plugins.lua
, and there are no functions exposed to remove added plugin specifications.Possible solution 1: Add a
remove
functionThis is a more imperative approach, I would prefer a declarative approach; i.e. you specify which plugins you need, and unused are cleaned up automatically.
Also, the
remove
call is something I'd never want to commit. In the previous case, I might have added aremove
call, resourced, and then remove the line again.But it would probably be the easier solution to the problem.
Possible solution 2: Add a
begin
/commit
cycleThis is inspired by VimPlug that I did use for many years - but I would not suggest an identical approach.
VimPlug, as far as I remember, builds up a list of plugins to install inside the
begin
/end
cycle, but doesn't install them until after callingend
. I would still suggest that plugins are installed after callingadd
, so you can configure them immediately afterwards, explicitly (as opposed to setting aconfig
function).So cleanup of extra installed plugins could happen in the final
end
call