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: Support sub plugins. (Not about sub directory) #1836

Closed
1 task done
hoofcushion opened this issue Dec 6, 2024 · 9 comments · Fixed by #1838
Closed
1 task done

feature: Support sub plugins. (Not about sub directory) #1836

hoofcushion opened this issue Dec 6, 2024 · 9 comments · Fixed by #1838
Labels
enhancement New feature or request

Comments

@hoofcushion
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.

图片

In this plugin structure, hc-nvim, hc-func, hc-substitute has to separates to 3 plugins to set it's lazy load stratagy.

图片

mini.nvim has similar plugin structure, which means each mini.nvim's sub plugin can't utilize lazy.nvim's lazy load mechanism. and splitery is required too.

Describe the solution you'd like

Allow lazy.nvim load plugins that only has main field, and in this situation, lazy.nvim tries to require(plugin.main) to get module, and only throw error when main coresponds module not exsist.

e.g. using mini.nvim

lazy.setup({
 "echasnovski/mini.nvim", -- add mini.nvim to rtp
 {
  main="mini.surround", -- call require("mini.surround").setup() directly, no wondering where it is
  host="echasnovski/mini.nvim", -- maybe a additional field to specify host plugin is more robust.
  config=true,
  keys="sa",
 }
})

This feature is usful for user writing local plugins on stdpath("config"), without worry about lazy failed on finding them.
And allow user to utilize lazy.nvim's lazy load feture to manage user configurations.

~/.config/nvim/lua/user/init.lua

local M={}
function M.setup()
 -- do some thing
end
return M

~/.config/nvim/init.lua

lazy.setup({
 {
  main="user", -- call the module above directly.
  config=true,
  event="BufEnter",
 }
})

For neovim distro that parasitic on lazy.nvim. it is also usful to manage how different part to be load, e.g. LazyVim has different module, each could has its trigger event, but currently LazyVim just load it all on init.

Describe alternatives you've considered

pass

Additional context

In my configuration hc-nvim, I wish my sub plugin hc-func and hc-substitute could lazy load too. And I don't want to create a bunch of repo for each sub plugin like mini.nvim.

@hoofcushion hoofcushion added the enhancement New feature or request label Dec 6, 2024
@hoofcushion
Copy link
Author

hoofcushion commented Dec 6, 2024

Basicly, a main field is enough to load a plugin, and the host field is to ensure lazy.nvim installed it's host plugin, for local configurations, host field is not needed.

@hoofcushion
Copy link
Author

图片
图片

Recent update check dir is valid plugin location, which means fake plugin spec is not allow, that breaks some configuration, it's not lazy.nvim's fault to check if dir is valid, but could there be another way to use lazy.nvim to lazy load sub plugins/ user configurations?

@max397574
Copy link
Contributor

it's not possible to just load a subdirectory
just by how neovim runtimepath works

so I'm quite sure lazy won't implement this

@folke
Copy link
Owner

folke commented Dec 6, 2024

yeah, not interested in this. Closing...

@folke folke closed this as not planned Won't fix, can't repro, duplicate, stale Dec 6, 2024
@hoofcushion
Copy link
Author

hoofcushion commented Dec 6, 2024

load a subdirectory

It's not about loading subdirectory, it's about allowing plugin spec with only main field, to be loaded...

@hoofcushion
Copy link
Author

Old version or lazy.nvim actually did provide this behavior, but it has broken by the latest version of forcing to check dir / url / dev. Which is unnecessary, lazy.nvim doesn't need to know where the plugin located. Since user promise it already in rtp.

@hoofcushion
Copy link
Author

hoofcushion commented Dec 6, 2024

Every plugin eventually needs a dir to load. Why coupled download and load functions together. Like, really? I can't load something that's already in my rtp. And things that not in my rtp were often easy to load? That was very weird.
That means I either had to split every component that has its own lazy logic into a single plugin, and create a repo, and maintain it each... or I had to write lazy load logic myself, providing general supports for plugin / subcomponents, even my plugin manager, Why?

@folke
Copy link
Owner

folke commented Dec 6, 2024

The fact that that used to work was simply a bug.
A plugin's directory is used in a lot of different places and I was frankly surprised that didn't already trigger any errors when using an invalid dir.

However, I just added support for virtual plugins.

I did a quick skim for all the places that use plugin.dir and made some changes where needed, but I'm not 100% sure I got them all.

You can use it like the example below. You can of course use any of the other plugin spec fields like main as well.

{
    "foobar",
    event = "VeryLazy",
    virtual = true,
    config = function()
      vim.notify("foo")
    end,
  }

@hoofcushion hoofcushion changed the title feature: Support sub plugins. feature: Support sub plugins. (Not about sub directory) Dec 6, 2024
@hoofcushion
Copy link
Author

Oh I didn't refresh my browser and sorry for changing issue name, I didn't know it would be solved that fast. Thanks.

folke pushed a commit that referenced this issue Dec 7, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
🤖 I have created a release *beep* *boop*
---


##
[11.16.0](v11.15.0...v11.16.0)
(2024-12-07)


### Features

* **plugin:** added support for virtual plugins. Closes
[#1836](#1836)
([ee64abc](ee64abc))


### Bug Fixes

* **plugin:** don't check if dir exists for virtual plugins
([656cf43](656cf43))
* **render:** show correct key for home. Fixes
[#1796](#1796)
([b08dba8](b08dba8))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
wroyca added a commit to wroyca/dotfiles that referenced this issue Dec 8, 2024
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

Successfully merging a pull request may close this issue.

3 participants