Allow `test.warnings` and `test.assertions` to be defined as either a
list, or a function coerced to a list.
When defined as a function, it is supplied an `expect` function which
provides some syntactic-sugar for defining simple expectations.
This is an alternative to the current approach of defining that `expect`
function on an ad-hoc basis.
I prefer this to adding `expect` to nixvim's lib because:
1. That would require having access to `lib`
2. IDK where in `lib` such a specialized function should live
There are some codepaths out there in the wild that seem to be
explicitly setting a buffer at build time. I'm not convinced that's a
sane thing to do, but I don't have time to dig any further right now.
See the discussion starting here:
https://github.com/nix-community/nixvim/pull/2712#issuecomment-2556330101
for more context.
This feels more correct to me: I believe we were registering a keymap
for all buffers, even if only some of them have experienced the relevant
autocmd.
I don't know if it's guaranteed here that `args.buf` always exists
(but maybe it's not a problem if it doesn't exist, because we'll still
register a keymap for all buffers?).
This fixes https://github.com/nix-community/nixvim/issues/2711
Expose our locked nixpkgs as the `nixpkgs.source` module options.
This only happens when `evalNixvim` is part of a lib that was provided
`flake` as an argument.
Stubbed the `nixpkgs.source` option for now. Eventually, this will be
used to construct `pkgs` internally. For now, it's purely informational.
Currently, we generate the lua code as soon as the value of the option
is not an empty attrs.
However, a case where the attrs only contains `null` values
(`nord_colorscheme = null; nord_foo = null;}` would pass the `if`
condition, but the generated lua table would still be empty because
`toLua` filters out those values.
Hence, we should directly check if the attrs would be translated to an
empty lua table or not to decide whether we should generate the lua
snippet or not.
Based on the `nixpkgs.overlays` option available in NixOS, allows users
to further customize the `pkgs` instance used when evaluating nixvim.
The standard module tests are now provided a few extra module args to
enable a test where we instantiate a custom nixpkgs instance.
The official method for obtaining the generated initRc content is from
wrapped neovim rather than from makeNeovimConfig helper. To use this
approach: first wrap neovim with the generated config, then override it
with our wrapperArgs.
This minimal implementation allows `nixpkgs.pkgs` to be defined, but
does not implement evaluating an instance from a pkgsPath when _not_
defined.
The `defaultPkgs` specialArg is dropped in favour of `nixpkgs.pkgs`
being defined. If it's not defined, an assertion is thrown.
In the future, a nixpkgs source path can be supplied, defaulting to the
flake's `inputs.nixpkgs`. Along with other `nixpkgs.*` options, this
will allow a `pkgs` instance to be evaluated within the module eval.
Gaetan Lepage
Matt Sturgeon
Sandro Jäckel
Jeremy Fleischman
Austin Horstman
Heitor Augusto
Stanislav Asunkin