-
Notifications
You must be signed in to change notification settings - Fork 397
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: Improve dev option usability #993
Comments
Just to expand on the alternative that is described here (which I think is a really good move forward) is the general explanation of that approach. Basically through these "snippets" (as used in the original issue body)/partial plugin specifications, as they are merged together it seems logical and intuitive that only things explicitly added in the specs by the user should be considered until the very end where lazy has as much user information as it can before making implicit decisions. If the user does not explicitly add This would most likely involve resolving the specs as the user provides them before calculating stuff like
Thanks so much to folke for all of the effort and amazing work put into lazy.nvim and huge thanks to @abeldekat for their help organizing the thoughts of these two issues. ❤️ |
Hi @mehalter, Thanks for the response, and for the term 'partial plugin specifications'. I think
This is already the case! Only the
Agree.
I don't think there is anything to resolve, except for the handling of the
Perhaps a little, but only when actually using the
No need to apologize in my opinion. I appreciate your commitment! To summarize, I think lazy.nvim already operates as you expect. Changing the handling of the |
Awesome, thanks for the explanation @abeldekat it doesn't quite work the way I expect since the I also agree that if it does only affect |
Don't understand the most of mentioned here. But just wondering if there is a way to use The issue I'm facing is, I use a plugin to manage all my luasnips. I frequently update them so I have set May be a solution to this can be included too. Edit: Now that I'm thinking about it, I can just do this, Edit: Tested it and working local plugin_path = '~/Workspace/nvim-snips'
local M = {
's1n7ax/nvim-snips',
name = 'snips',
dir = plugin_path,
}
if vim.fn.isdirectory(plugin_path) == 1 then
M.dev = true
M.dir = plugin_path
end
return M |
…om the plugin's old dir. Show an error in this case. Fixes #993
Just pushed an update where both One important caveat though. During spec parsing, some plugins may already get partially loaded if they are When we detect a |
Thanks! |
Did you check the docs?
Is your feature request related to a problem? Please describe.
A plugin can be configured in multiple locations, or have multiple specs in the same location.
In this request, the term
snippet
is used, referring to such a location.When a plugin is configured across multiple snippets, and the user applies the
dev
marker on one of those snippets, the effect can be hard to reason about.See the following issues:
dev
and dependencies #982dev
and imports #985The docs regarding
dir
anddev
Importing specs
Plugin spec
Configuration
In the examples
Analyzing the concept
The
dir
anddev
keywords are conceptually the same.The
dev
keyword implicitly sets thedir
, according to:When applied on an individual snippet, the
dir
is only changed on that snippet, and can be easily overriddenWhen using
config.dev
inrequire("lazy").setup()
, thedev
option triggers the calculation of thedir
in all matching snippets.Examples: Order matters
dev
on first snippetThe results would be the same if the first line is changed into:
dev
on second snippetNote the line containing "BUG" in the last code fragment.
The snippet is a valid short named specification, thus the
dev
marker should have triggered the calculation ofdir
The result differs if the last line is changed into:
With this change,
dir
is applied correctlyUsage
dir
propertyThe user has no specific need to maintain multiple snippets for this plugin.
The user makes sure his snippet is not overridden with another
dir
.config.dev
onsetup
Describe the solution you'd like
dir
property as is.dev
marker from the plugin spec.config.dev
onsetup
.config.dev.patterns
, and also has adir
specifiedA technical thought
Currently,
config.dev.patterns
is handled inPlugin.add
. Perhaps that code could be handled inPlugin.fix_disabled
, a sanitation step. In that case,Plugin.fix_disabled
needs to be renamed.Update 2023.09.08: I don't think my technical suggestion above is valid. The
dir
property is needed whenimporting
specs.Describe alternatives you've considered
Never overwrite a
dir
once its set on a snippet. Requires changingPlugin.merge
Additional context
See the following issues:
dev
and dependencies #982dev
and imports #985The text was updated successfully, but these errors were encountered: