Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Local plugins don't get cleaned up #1560

Closed
3 tasks done
dpetka2001 opened this issue Jun 26, 2024 · 1 comment · Fixed by #1565
Closed
3 tasks done

bug: Local plugins don't get cleaned up #1560

dpetka2001 opened this issue Jun 26, 2024 · 1 comment · Fixed by #1565
Labels
bug Something isn't working

Comments

@dpetka2001
Copy link
Contributor

dpetka2001 commented Jun 26, 2024

Did you check docs and existing issues?

  • I have read all the lazy.nvim docs
  • I have searched the existing issues of lazy.nvim
  • I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.11.0-dev-311+g9dc09a4cd

Operating system/version

Linux Mint 21.3

Describe the bug

I use todo-comments.nvim as a local plugin to take advantage of a yet unmerged PR. I added dev = true to the plugin's spec. However when I launch Lazy UI, it shows that the plugin should be cleaned up. I press X to clean the plugin, but nothing happens and it keeps showing up in the Lazy UI as a candidate to be cleaned up.

Maybe, I'm not doing something right (I just did what I've been doing so far before the latest big Lazy update) or is this something that should be looked into?

Steps To Reproduce

  1. Add dev = true to the todo-comments.nvim plugin spec and restart Neovim.
  2. It shows 2 entries of todo-comments, one to be cleaned up and another one with orange circle in the front that is the local version.

Expected Behavior

The plugin should be cleaned up after pressing X in the Lazy UI and not show up as a candidate for cleaning up again.

I use LazyVim and managed to get around this by defining enabled = false in the plugin spec, then I was able to clean up the plugin by pressing X and then removed enabled = false from the plugin spec and the plugin didn't appear as a candidate to clean up again and used the local version instead.

It doesn't happen with the minimal repro when you start from a clean slate and the plugins get installed for first time.

PS: Actually this also happens with the minimal repro. I added in the minimal repro the todo-comments.nvim spec. Notice that dev = true is commented out at start. If you run nvim -u repro.lua then the installation will take place. After the first installation, if you uncomment dev = true and restart Neovim, you will observe what I've described previously.

If you add enabled = false you will be able to clean up and then removing enabled = false will no longer show the candidate for clean up.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
	{
		"folke/todo-comments.nvim",
		 -- dev = true,
	},

  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@dpetka2001 dpetka2001 added the bug Something isn't working label Jun 26, 2024
@folke
Copy link
Owner

folke commented Jun 26, 2024

I know what's wrong here. Will work on a fix. Thank you for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants