lib/vim-plugin: Add support for luaConfig
#2624
Conversation
traxys
force-pushed
the
vim-lua-config
branch
from
a98a4f9 to
4f1c868
Compare
traxys
force-pushed
the
vim-lua-config
branch
2 times, most recently
from
86fb737 to
d63acc9
Compare
This will be used to implement `luaConfig` for plugins that use global variables for their configuration
traxys
force-pushed
the
vim-lua-config
branch
from
d63acc9 to
3542fd5
Compare
| (lib.optionalAttrs createSettingsOption { | ||
| globalsPre = lib.nixvim.mkIfNonNull cfg.luaConfig.pre; | ||
| globalsPost = lib.nixvim.mkIfNonNull cfg.luaConfig.post; | ||
| }) |
There was a problem hiding this comment.
Initial reaction: I'm not a fan of this.
I don't think it makes sense to assign lua code to an option named "globals*".
| // { | ||
| globalsPre = lib.mkOption { | ||
| type = lib.types.lines; | ||
| default = ""; | ||
| internal = true; | ||
| }; | ||
|
|
||
| globalsPost = lib.mkOption { | ||
| type = lib.types.lines; | ||
| default = ""; | ||
| internal = true; | ||
| }; | ||
| }; |
There was a problem hiding this comment.
I guess the intention is that this is lua code injected pre/post the lua impl for the globals option.
But reading the option name I'd half-expect to be able to assign globals earlier or later than normal.
This feels like working around a poor design rather than an objective improvement.
There was a problem hiding this comment.
I'm wondering if instead, each plugin should be responsible for using vim.g[k] = itself. Perhaps within luaConfig.init ?
Yes, this would mean vim-plugins aren't taking advantage of the globals option, and consiquently end-users won't see the configured globals when inspecting the option's value. But perhaps that is worth it in order to locate the globals in a more predictable location?
There was a problem hiding this comment.
Another idea: Perhaps the luaConfig submodule could also be used for non-plugin modules too? E.g. we could have a globalsLuaConfig option, and move the lua impl to globalsLuaConfig.init?
(maybe rename init something like main, content, text, etc?)
There was a problem hiding this comment.
I'm not really a fan of any of the three solutions, tbh. So open to alternative proposals too.
There was a problem hiding this comment.
I'm wondering if instead, each plugin should be responsible for using
vim.g[k] =itself. Perhaps withinluaConfig.init?Yes, this would mean vim-plugins aren't taking advantage of the
globalsoption, and consiquently end-users won't see the configured globals when inspecting the option's value. But perhaps that is worth it in order to locate the globals in a more predictable location?
I though about that, but I think setting the global options in nix is a bit better, as it allows to do more compile time stuff (though you could still do compile time stuff by accessing the plugin's settings)
There was a problem hiding this comment.
Another idea: Perhaps the
luaConfigsubmodule could also be used for non-plugin modules too? E.g. we could have aglobalsLuaConfigoption, and move the lua impl toglobalsLuaConfig.init?(maybe rename
initsomething likemain,content,text, etc?)
There could be a use for it, for example to define helpers for keymaps, or options
There was a problem hiding this comment.
I still like the global option interface being used, too. I guess I am not too sure of when a vim plugin would use it, though. Almost feels like we would start blending the mkNeovimPlugin and mkVimPlugin stuff together into one solution that has these arguments to declare what functionality and routing is done. Could just add an argument for whether its a vim or neovim plugin so that we can properly group things and/or gate defaults.
This series allows to use
luaConfigfor vim plugins that are configured through global variables