You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In lazy's UI, substitute.nvim is shown in the disabled section, using a different color.
Plugin vim-abolish is only used inside the spec of substitute.nvim.
However, vim-abolish is "just" disabled, and is shown in the clean section of the UI.
Describe the solution you'd like
When plugin A is marked as conditional, and plugin B is only used inside the dependencies of plugin A, plugin B should also be marked as conditional. This prevents plugin B from being cleaned.
…onal plugins (#1058)
* feat(plugin): dont include plugin spec fragments for disabled or optional plugins
* test: fixed tests
* fix(plugin): calculate handlers after disabling plugins
* fix(plugin): clear Plugin._.super when rebuilding
* fix(ui): dont process handlers for disabled plugins
* test: added tests for disabling fragments
* fix(plugin): ignore any installed deps of a disabled conditional plugin. Fixes#1053
is there anything you need to do not to clean disabled plugins from lock file? when I do :Lazy restore it removes all disabled plugins from the lock file. By disabled I mean things like:
Did you check the docs?
Is your feature request related to a problem? Please describe.
Example:
In lazy's UI,
substitute.nvim
is shown in thedisabled
section, using a different color.Plugin
vim-abolish
is only used inside the spec ofsubstitute.nvim
.However,
vim-abolish
is "just" disabled, and is shown in theclean
section of theUI
.Describe the solution you'd like
When plugin A is marked as conditional, and plugin B is only used inside the dependencies of plugin A, plugin B should also be marked as conditional. This prevents plugin B from being cleaned.
Related: bug: plugins not loaded due to cond are not contained in the lazy-lock.json file
Perhaps it would make sense to not remove conditional plugins from
lazy-lock.json
.Describe alternatives you've considered
...
Additional context
Folke, if you are interested in this proposal, I could write a PR or extend feat(core): If a plugin is not enabled, ignore all specs in its dependencies
The text was updated successfully, but these errors were encountered: