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

feature: Provide indication in :Lazy modal that shows when local plugins are used vs not #1802

Open
1 task done
Drew-Daniels opened this issue Nov 5, 2024 · 5 comments
Open
1 task done
Labels
enhancement New feature or request

Comments

@Drew-Daniels
Copy link

Did you check the docs?

  • I have read all the lazy.nvim docs

Is your feature request related to a problem? Please describe.

Thanks for making this plugin! lazy.nvim has been incredibly easy to use and massively helpful in my development workflow.

Feature Request

It seems like when you run :Lazy there are different colors that are supposed to indicate whether or not you are using a plugin locally or one downloaded from a remote source like GitHub. In my case, downloaded plugins have an orange circle and local ones have a pink circle.

image

I think this is helpful, but I've noticed a couple issues with this:

  1. It looks like the "local" color is just based on whether or not you have configured a plugin with the dir property set
  • I.e., it doesn't matter if the dir points to a non-existent folder on your filesystem
  1. This doesn't tell users if the local or remote version of this plugin is actually being used
  • I have forks of many plugins, where I just leave the dir property set in my plugin configuration, but comment out the dev = true property, so I can use the remote version in most cases, but use my local version when I need to debug something (by uncommenting the dev = true line.

I would expect that the circle would be colored orange in this case, because I'm using the remote version of the plugin, but it still remains the "local" color, which I feel like it gives users the wrong idea that a local plugin is being used when it may not be.

Describe the solution you'd like

I think it would make more sense for:

  • The "local" (pink) color to be used when all of the following conditions are true:
    • You have configured the dir property of a plugin configuration
    • This dir property points to an existent folder
    • The dev property of a plugin configuration is set to true
  • The "remote" (orange) color to be used when one of the above is false

Describe alternatives you've considered

N/A

Additional context

The screenshot below shoes that the codeium.vim entry has a pink circle next to it, when I think it should be orange to indicate that this local plugin is not being used (in this case, because I have dev = false for this plugin)

image

local lazypath = vim.fn.stdpath("data") .. "/lazy/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",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

return require("lazy").setup({
  -- ...
  {
    "Exafunction/codeium.vim",
    event = "BufEnter",
    dir = "~/projects/codeium.vim",
    -- dev = true,
  },
  -- ...
})
@Drew-Daniels Drew-Daniels added the enhancement New feature or request label Nov 5, 2024
@dpetka2001
Copy link
Contributor

The dir in the plugin spec is used to indicate a local directory where the plugin resides. dev = true is used to also indicate the local use of a plugin but with the default directory that is configured under config.dev instead if a dir property is not present.

So, both options indicate the use of a local plugin and if you want to use the remote repo, then you should just comment them both out.

Relevant sources: https://lazy.folke.io/spec#spec-source and https://lazy.folke.io/configuration

@Drew-Daniels
Copy link
Author

Thanks @dpetka2001 , I hadn't seen the config.dev.path configuration before.

I think my confusion mostly stems from the fact that I think a different color being used next to a plugin would indicate that a local version is being used. Because right now, there's a different color displayed regardless of whether a local plugin is being used, and there could be a variety of reasons its not, including:

  • Using an invalid file path for dir, or
  • Having dir set to a valid path, but dev = true not set

I guess the behavior isn't that hard to remember once you're aware of if it, it just doesn't seem as intuitive as I think it could be (personally)

@dpetka2001
Copy link
Contributor

Are you sure your local plugin is not being used? What does it show in Lazy UI if you go with your cursor on the plugin and press Enter? dev = true doesn't have to be set to use a local plugin. If you have dir set it will use the local plugin regardless if you have set dev = true or not.

The problem about dir not being a valid path is a different matter and I believe there's another open issue for it, although I believe that it's the responsibility of the user to use the correct path. Possibly there could be a check to validate if dir is a directory that exists, but I don't think that typos errors could easily be taken into account.

@Drew-Daniels
Copy link
Author

Actually, I apologize, I had misread your earlier comment. It looks like setting config.dev.dir to where my local plugins are located, and toggling dev = true on my individual plugin configurations worked as you described.

My misunderstanding stemmed from thinking that dir and dev were intended to be used together, but like you said, it's now clear to me that dir is only necessary when local plugins are located outside of the config.dev.path directory. So I guess there's not an issue here.

Thanks for the quick response and for the patience on this user error 😬

@dpetka2001
Copy link
Contributor

No reason to apologize. I'm just happy to help a fellow user like I am myself 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants