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
This series allows to use
luaConfigfor vim plugins that are configured through global variables