Open henrispriet opened 1 month ago
As per the example, mkVimPlugin should convert bool settings options to int. https://github.com/nix-community/nixvim/blob/49452662b7b4dd2467cbac19e0f9820d570d8976/lib/vim-plugin.nix#L57-L62
The example was added by @GaetanLepage in 97fb6d6a
That said, looking at the implementation, I can't see any type conversion being done. It only seems to add the prefix to the option name: https://github.com/nix-community/nixvim/blob/49452662b7b4dd2467cbac19e0f9820d570d8976/lib/vim-plugin.nix#L107
This likely affects a ton of plugins, as many will assume the example is correct and bools are properly converted to int.
I see two solutions to this:
mkVimBool
option helper, with type oneOf [ true false 1 0 ]
The mkVimPlugin approach could replace nameValuePair
with a custom processGlobal
(name TBC):
processGlobal = prefix: name: value: {
name = prefix + name;
value =
if isBool value then
if value then 1 else 0
else
value;
};
# Used like:
globals = mapAttrs' (processGlobal globalPrefix) globals;
The mkVimBool
approach could have an apply
function, e.g.
apply =
v:
if isBool v then
if v then 1 else 0
else
v;
On the other hand, in the spirit of rfc42, maybe we should encourage using the appropriate type, in this case enum [0 1]
.
We could add temporary support for booleans along with a deprecation warning when they are used?
I'm dumb, of course vim options can be booleans. Therefore we can't assume nix booleans should be converted to ints.
Instead, the settings-example should be fixed and any affected options should have their type changed to enum [0 1]
.
IDK if there's a good way to transition affected options without immediately breaking users' configs. I guess any affected users already had (silently) broken configs anyway, so this may not be important.
One way we could do this would be to create a custom type, equivalent to enum [0 1 true false]
but have the type's description
be "either 0 or 1".
That way we aren't documenting boolean support, but we could still check for boolean definitions and print an appropriate warning.
Yeah for configs that are already broken I don't think it's too bad to introduce a breaking change
lazygit
unstable
unstable
Description
When
plugins.lazygit.settings.use_custom_config_file_path
is set totrue
, lazygit.nvim does not recognize it.NixVim says this option is a bool and passes it on as such into the generated
init.lua
, but lazygit.nvim checks if the option is 1 to enable the feature.Minimal, Reproducible Example (MRE)
Workaround