-
-
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
plugins/lz-n: init #1874
plugins/lz-n: init #1874
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.
Thanks for working on this!
It's looking good, I've just left a few comments below to hopefully improve things further
I have made the changes suggested by the review. A question more about GitHub ettiquette. Should I keep these changes in its own commit, or should i squash them to the original commit? |
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 have made the changes suggested by the review.
Thanks!
A question more about GitHub ettiquette. Should I keep these changes in its own commit, or should i squash them to the original commit?
Personally, it doesn't bother me either way.
Having separate commits can be beneficial since that way you can more easily tell what has changed, although it's still possible to diff force-pushes.
The most important thing is that it is easy to squash the changes once the PR has moved on enough that having separate commits is no longer needed.
On more complex PRs you can end up with conflicts when squashing lots of small changes that were committed in a different order.
Also, if you're not aware, git commit --fixup
and git rebase -i --autosquash
can be very useful.
I've focused this review on the plugins
option and attempting to make it fit better with RFC42.
See this section of our contributing guide, or the RFC itself.
For some of the discussion points I'd appreciate input from the other maintainers @nix-community/nixvim
Thank you for your review and guidance! I made most of the changes suggested. Some things still need input from reviewers. |
I think I resolved most of the concerns. All the magic for setting options was removed. If there is anything else I need to change, please let me know. |
e08c70d
to
a91767d
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.
A few nits, but mostly just discussion points.
The main blocker now is discussing the best way to handle documenting unkeyed attrs as part of a well-defined submodule.
The PR itself is in good shape, well done! 🎉
plugins/pluginmanagers/lz-n.nix
Outdated
submodule { | ||
freeformType = attrsOf anything; | ||
options = { | ||
__unkeyed = mkOption { |
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.
listToUnkeyedAttrs
uses __unkeyed-1
:
Lines 15 to 17 in 47b6c48
listToUnkeyedAttrs = | |
list: | |
builtins.listToAttrs (lib.lists.imap0 (idx: lib.nameValuePair "__unkeyed-${toString idx}") list); |
I guess for consistency we should too? On the other hand maybe it's better is this doesn't specify an index, to allow users to add unkeyed table entries with any index (via freeform 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.
I don't think we've ever had an "unkeyed" option definition before... So far all unkeyed attrs have been in freeform definitions.
I can't see a better alternative, it just feels as though we're now more publicly exposing the messy side of trying to map nix values to lua tables. And in doing so committing more solidly to our current strategy? 🫤
@traxys are you happy with this approach?
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.
Thanks, I think this is pretty much done. There's just a couple thinks I'd like a second opinion on from another maintainer.
Other than that it's just nits below. Now the PR is pretty much done, could you try and keep the commits squashed to just the two "add maintainer" and "add plugin" commits?
Also, sorry this took a while for me to look at. If it's ready for review and you have been waiting, don't hesitate to ping one of us, since it's easy for individual PRs to get forgotten about otherwise!
plugins/pluginmanagers/lz-n.nix
Outdated
enabled = helpers.defaultNullOpts.mkStrLuaFnOr bool true '' | ||
When false, or if the function returns false, then this plugin will not be included in the spec. | ||
This option corresponds to the `enabled` property of lz.n. | ||
''; | ||
beforeAll = helpers.mkNullOrLuaFn "Always executed before any plugins are loaded."; | ||
before = helpers.mkNullOrLuaFn "Executed before this plugin is loaded."; | ||
after = helpers.mkNullOrLuaFn "Executed after this plugin is loaded."; | ||
load = helpers.mkNullOrLuaFn "Can be used to override the `vim.g.lz_n.load()` function for this 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.
@GaetanLepage @traxys are we happy to introduce new strLua options if we're considering deprecating strLua?
I guess this is fine since we haven't properly discussed it yet and made a decision?
Great, thanks for taking a look at it again. I applied all the changes and some other style changes suggested by GaetanLepage on #1979. I sqashed all comits as requested. No worries about the wait, I took that time to improve my personal nixvim config ;). Regarding the |
I think it's fine. Nixvim is full of strLua, so this won't make any eventual deprecation notably worse. I think other maintainers will take a look over the next few days 🤞 |
Thanks for your persistent work & dedication on these PRs! |
Seems like a buildbot issue? Just strange it's only happening on this PR. Will try rebuilding. |
Great!
Thanks to all of you for maintaining this awesome project.
I saw the error, but since it was not in the lz-n tests I didn't know how to troubleshoot 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.
Minor nit, otherwise good to me !
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, are you happy @GaetanLepage?
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.
Yes, let's go !
@Mergifyio queue |
🛑 The pull request has been removed from the queue
|
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 78abafe |
@psfloyd just wanted to let you know that I've added a new |
This is the first PR of splitting PR #1866.
This PR adds:
plugins.lz-n
and its options for lazy-loading plugins using lz.n.plugins.lz-n
.