Skip to content
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

Merged
merged 1 commit into from
Sep 22, 2024

Conversation

traxys
Copy link
Member

@traxys traxys commented Jul 16, 2024

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 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.

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 on plugins.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 a config option, so I had to write some code to skip adding this new option for that plugin

Old 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:

  • Easily splitting the plugin in another lua file, for example for a specific filetype
  • Passing the configuration to a lazy loading provider

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.

@traxys traxys requested a review from MattSturgeon July 16, 2024 19:44
GaetanLepage
GaetanLepage previously approved these changes Jul 16, 2024
Copy link
Member

@GaetanLepage GaetanLepage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM !

lib/neovim-plugin.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
@MattSturgeon
Copy link
Member

Can we revisit this now the CI is working again?

@traxys
Copy link
Member Author

traxys commented Aug 4, 2024

Yup, I thought about it a bit and I think I'll go with your suggestion, of creating a single lua block with pre|post

@traxys
Copy link
Member Author

traxys commented Aug 19, 2024

@MattSturgeon I re-wrote the PR and amended the description with the new implementation details!

Copy link
Member

@MattSturgeon MattSturgeon left a 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!

lib/neovim-plugin.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
plugins/colorschemes/ayu.nix Outdated Show resolved Hide resolved
plugins/languages/rust/rustaceanvim/default.nix Outdated Show resolved Hide resolved
@MattSturgeon MattSturgeon changed the title lib/neovim-plugin: Introduce configLua(Pre|Post)? options lib/neovim-plugin: Introduce plugins.*.config.* options Aug 19, 2024
@traxys traxys force-pushed the configLuaPlugin branch 2 times, most recently from ee22c8d to 7c6e818 Compare August 20, 2024 20:20
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
plugins/utils/flash.nix Outdated Show resolved Hide resolved
plugins/utils/hydra/default.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
plugins/languages/rust/rustaceanvim/default.nix Outdated Show resolved Hide resolved
lib/neovim-plugin.nix Outdated Show resolved Hide resolved
@traxys traxys changed the title lib/neovim-plugin: Introduce plugins.*.config.* options lib/neovim-plugin: Introduce plugins.*.luaConfig.* options Aug 28, 2024
MattSturgeon
MattSturgeon previously approved these changes Aug 29, 2024
Copy link
Member

@MattSturgeon MattSturgeon left a 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).

lib/types.nix Outdated Show resolved Hide resolved
khaneliman
khaneliman previously approved these changes Aug 29, 2024
Copy link
Contributor

@khaneliman khaneliman left a 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

@traxys traxys mentioned this pull request Sep 9, 2024
@stasjok
Copy link
Contributor

stasjok commented Sep 14, 2024

Maybe wrap the config in do ... end block? Or even add an additional option like wrapInDo default true. This PR is very useful, but usually I try to write self-contained blocks of code and do block ensures that I don't pollute locals or don't override something unintentionally.

@@ -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')
Copy link
Contributor

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.

@khaneliman khaneliman mentioned this pull request Sep 21, 2024
@traxys traxys force-pushed the configLuaPlugin branch 2 times, most recently from ca5771d to d8e1b37 Compare September 21, 2024 20:56
plugins/utils/rest.nix Outdated Show resolved Hide resolved
@traxys
Copy link
Member Author

traxys commented Sep 21, 2024

Maybe wrap the config in do ... end block? Or even add an additional option like wrapInDo default true. This PR is very useful, but usually I try to write self-contained blocks of code and do block ensures that I don't pollute locals or don't override something unintentionally.

Very good idea, though I think I'll implement that in a follow-up PR (meanwhile you can simulate it by adding a do in luaConfig.pre an end in luaConfig.post)

@traxys traxys dismissed stale reviews from khaneliman and MattSturgeon September 21, 2024 22:14

Stale review

lib/types.nix Outdated Show resolved Hide resolved
plugins/utils/rest.nix Outdated Show resolved Hide resolved
Copy link
Contributor

@khaneliman khaneliman left a 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

Copy link
Member

@MattSturgeon MattSturgeon left a 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";
Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member

@MattSturgeon MattSturgeon Sep 22, 2024

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.

Copy link
Contributor

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";
Copy link
Member

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)";
Copy link
Member

@MattSturgeon MattSturgeon Sep 22, 2024

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.

Copy link
Contributor

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.

Copy link
Member Author

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
Comment on lines 139 to 140
(lib.mkBefore config.pre)
(lib.mkAfter config.post)
Copy link
Member

@MattSturgeon MattSturgeon Sep 22, 2024

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?

Copy link
Contributor

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.

@traxys traxys force-pushed the configLuaPlugin branch 4 times, most recently from f403a1d to f5c3b13 Compare September 22, 2024 15:54
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`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Suggested change
This is simply sugar around `lib.nixvim.utils.mkBeforeSection content`
This is the same as `content = lib.mkOrder ${(lib.nixvim.utils.mkBeforeSection null).priority} ""`

?

Copy link
Member Author

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

Copy link
Member

@MattSturgeon MattSturgeon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, LGTM!

Comment on lines +145 to +146
(lib.nixvim.utils.mkBeforeSection config.pre)
(lib.nixvim.utils.mkAfterSection config.post)
Copy link
Member

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.

@traxys
Copy link
Member Author

traxys commented Sep 22, 2024

@Mergifyio queue

Copy link
Contributor

mergify bot commented Sep 22, 2024

queue

✅ The pull request has been merged automatically

The 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.
Copy link
Contributor

mergify bot commented Sep 22, 2024

This pull request, with head sha d2f9e011d9c6e3d765422b78039e61ddf9e69749, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha d2f9e011d9c6e3d765422b78039e61ddf9e69749 is part of the main branch, it will mark this pull request as merged.

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 configLuaPlugin, this means GitHub will fail to detect the merge.

@mergify mergify bot merged commit d2f9e01 into nix-community:main Sep 22, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Append arbitrary lua code before or after generated plugin setup
5 participants