Conversation
MattSturgeon
left a comment
There was a problem hiding this comment.
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? |
MattSturgeon
left a comment
There was a problem hiding this comment.
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
MattSturgeon
left a comment
There was a problem hiding this comment.
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.
listToUnkeyedAttrs uses __unkeyed-1:
Lines 15 to 17 in 47b6c48
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.
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?
MattSturgeon
left a comment
There was a problem hiding this comment.
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.
@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. |
GaetanLepage
left a comment
There was a problem hiding this comment.
Minor nit, otherwise good to me !
MattSturgeon
left a comment
There was a problem hiding this comment.
LGTM, are you happy @GaetanLepage?
|
@Mergifyio queue |
🛑 The pull request has been removed from the queue
|
✅ The pull request has been merged automaticallyDetailsThe 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-nand its options for lazy-loading plugins using lz.n.plugins.lz-n.