lewis6991 / pckr.nvim

Spiritual successor of https://github.com/wbthomason/packer.nvim
MIT License
243 stars 13 forks source link

Allow cleanup when reloading the configuration #24

Closed stroiman closed 2 months ago

stroiman commented 2 months ago

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

require("pckr").add({
  "catppuccin"
})

And sourced my config, and get an error, because the plugin spec was wrong. I fixed the config,

require("pckr").add({
  "catppuccin/nvim"
})

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 function

This 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 a remove 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 cycle

This 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 calling end. I would still suggest that plugins are installed after calling add, so you can configure them immediately afterwards, explicitly (as opposed to setting a config function).

local pckr = require("pckr")
pckr.begin()
require("load_and_initialize_plugin_1") 
require("load_and_initialize_plugin_1")
-- Small experiment, just place this in the main init.lua for now, I may move it later
pckd.add("plugin_3")
require("plugin_3").setup({ ... })
pckr.end() -- Remove previously installed unused plugins here

So cleanup of extra installed plugins could happen in the final end call

lewis6991 commented 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.

stroiman commented 2 months ago

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.

lewis6991 commented 2 months ago

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.