-
-
Notifications
You must be signed in to change notification settings - Fork 302
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
lib/neovim-plugin: Introduce plugins.*.luaConfig.*
options
#1876
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM !
Can we revisit this now the CI is working again? |
Yup, I thought about it a bit and I think I'll go with your suggestion, of creating a single lua block with |
03e1061
to
785f7dc
Compare
@MattSturgeon I re-wrote the PR and amended the description with the new implementation details! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial thoughts and questions, thanks for continuing to work on this!
plugins.*.config.*
options
ee22c8d
to
7c6e818
Compare
7c6e818
to
ce3e294
Compare
ce3e294
to
6868413
Compare
plugins.*.config.*
optionsplugins.*.luaConfig.*
options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any issues, but it might be nice to mark luaConfig.final
as internal?
I also think it may be more powerful/future-proof to make final
a lines type and make use of ordered definitions, see #1876 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really like where this PR has gone in giving more control over lua relevant to a plugin
Maybe wrap the config in |
plugins/utils/ccc.nix
Outdated
@@ -248,7 +248,7 @@ helpers.neovim-plugin.mkNeovimPlugin config { | |||
# ccc requires `termguicolors` to be enabled. | |||
opts.termguicolors = lib.mkDefault true; | |||
|
|||
extraConfigLua = '' | |||
plugins.ccc.luaConfig.init = '' | |||
ccc = require('ccc') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not introduced by this PR but why is it not local? Hydra later too.
ca5771d
to
d8e1b37
Compare
d8e1b37
to
fa2d4eb
Compare
Very good idea, though I think I'll implement that in a follow-up PR (meanwhile you can simulate it by adding a |
fa2d4eb
to
a747ffe
Compare
Stale review
a747ffe
to
3a63e2a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM I think this will be a very useful change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall! I just wonder if the descriptions could be clarified?
lib/types.nix
Outdated
pre = lib.mkOption { | ||
type = types.lines; | ||
default = ""; | ||
description = "Configuration before the initialization of the plugin"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this description could clarify that pre
is actually merged into init
with a "before" merge-order priority
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like an implementation level detail that would cloud the purpose of the option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the fact that pre
and post
are merged into init
is purely an implementation detail:
- End users will be exposed to this detail when reading the final
init
value mkOrder
is a user-facing utility- how mkOrder interacts with pre & post could be important to some users
I think the implementation is fine, so long as users aren't surprised by it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* End users will be exposed to this detail when _reading_ the final `init` value
True, this makes sense to me as a reason to include some mention, then.
lib/types.nix
Outdated
post = lib.mkOption { | ||
type = types.lines; | ||
default = ""; | ||
description = "Configuration after the initialization of the plugin"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same
lib/types.nix
Outdated
init = lib.mkOption { | ||
type = types.lines; | ||
default = ""; | ||
description = "Initialization code (between pre & post)"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same;
"between" pre&post is actually a little misleading. Anyone that reads init
will see it as including pre&post.
Anyone who uses mkOrder
on init may also be confused when pre&post get merged in-between their ordered definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... this makes me not like tying them to the same mkOrder merge if we can have this interaction. It should be set that pre comes before init and post comes after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think I should change the name, to something like config
or content
lib/types.nix
Outdated
(lib.mkBefore config.pre) | ||
(lib.mkAfter config.post) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it better to use non-standard merge priority numbers?
E.g. what would we expect to happen when someone uses:
pre = "foo";
init = mkBefore "bar";
Currently they would both be merged at priority 500, however we can't know just from reading the definition if we'll get "foo\nbar"
or "bar\nfoo"
.
I think users would expect pre
to be merged earlier than mkBefore and post
to be merged after mkAfter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely a niche case, but makes sense to at least prevent default priority overrides from messing with ordering.
f403a1d
to
f5c3b13
Compare
lib/types.nix
Outdated
default = ""; | ||
description = '' | ||
Lua code inserted at the start of the plugin's configuration. | ||
This is simply sugar around `lib.nixvim.utils.mkBeforeSection content` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is simply sugar around `lib.nixvim.utils.mkBeforeSection content` | |
This is the same as using `lib.nixvim.utils.mkBeforeSection` when defining `content`. |
Or maybe something like
This is simply sugar around `lib.nixvim.utils.mkBeforeSection content` | |
This is the same as `content = lib.mkOrder ${(lib.nixvim.utils.mkBeforeSection null).priority} ""` |
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer the first one
f5c3b13
to
6c688ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, LGTM!
(lib.nixvim.utils.mkBeforeSection config.pre) | ||
(lib.nixvim.utils.mkAfterSection config.post) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly speaking, these should each be wrapped in mkIf (config.pre != "")
, to avoid unnecessary empty lines when no pre/post is defined.
Or we could drop their default and use isDefined
. Or we could keep their default and use highestPrio < 1500
.
Regardless of the approach used, it will likely end up kinda messy. Therefore I don't think we need to necessarily tackle it in this PR.
6c688ec
to
0aa8ff6
Compare
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at d2f9e01 |
This commit adds a `plugins.<name>.luaConfig` section controlling the plugin specific configuration. The section contains the internal `init` option, containing the plugin's initialization code. It also contains the public `pre` and `post` options, that allow to add code before & after the `init` section Finally, it contains the `final` option, being the concatenation of the three previous options.
0aa8ff6
to
d2f9e01
Compare
This pull request, with head sha This pull request will be automatically closed by GitHub.As soon as GitHub detects that the sha It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch |
Resolves #1407
This commit adds a
plugins.<name>.config
section controlling the plugin specific configuration.The section contains the internal
init
option, containing the plugin's initialization code.It also contains the public
pre
andpost
options, that allow to add code before & after theinit
sectionFinally, it contains the
final
option, being the concatenation of the three previous options.I would have like to have a
location
option that allows to specify where to add the configuration option, it could be useful for rustaceanvim that needs to put the config in different places depending onplugins.lsp.enable
, but that ended up in infinite recursions.This option could also have been useful for lazy loading, as it may have enabled to add the configuration in a separate function to accomodate lazy loading.
The implementation is a bit less clean than I would have liked, as the
flash
plugin already defines aconfig
option, so I had to write some code to skip adding this new option for that pluginOld description
Those new options are scope to the plugin they help to configure. Those options should be preferred internally to using the raw
extraConfigLua(Pre|Post)?
option, as it allows being more flexible with how the configuration is generated.This commit does not introduce any customization, but doing this can allow things like:
This also allows users to define helper functions close to the plugins they are used into, allowing a more modular configuration
This improvement is only available to plugins using mkNeovimPlugin right now.