This commit replaces stub plugins with the shared ones from utils
module.
This also removes separate tests for checking python and lua
dependencies. This is now tested in the 'default' test thanks to
`pluginChecks` code.
This commit finalizes using shared utils stub plugins for
performance.byteCompileLua tests.
To re-use more code from utils module, 'pluginChecksFor', 'libChecksFor'
and 'pythonChecksFor' functions were introduced. These functions
generate a check code for the given plugins/libs names.
Previously only extraLuaPackages themselves were byte-compiled, not
theirs dependencies. This commit fixes that by compiling lua packages
recursively. It uses byte-compile-lua-lib.nix shared file.
Also this commit uses the shared stub lua libraries for extraLuaPackages
byte-compiling test.
This commit replaces custom lua plugins in tests with shared stub
plugins from utils module.
After this change the test has started to fail. Debugging this issue
I found out that dependencies of plugins weren't processed.
This commit improves the test assertion to detect duplicated
dependencies in this case and fixes the underlying issue by also
processing dependencies.
This commit introduces a shared utils module for future use in
performance tests. It includes lua libraries and plugins of various
types and dependencies. Additionally, it provides lua code snippets to
verify that all features supplied by the plugins are functioning
correctly.
Previously, to determine if a file is byte-compiled, a simple binary
file detection was used, specifically checking if it contained any null
bytes. This commit updates the check to read the file header and compare
it with a known LuaJIT header.
Previously path was concatenated using string interpolation. This commit
switches from string interpolation to path interpolation.
The problem is nix will copy the "${directory}" to a new store
object, meaning anything outside its root won't be available.
From the nix manual:
> A path in an interpolated expression is first copied into the Nix
> store, and the resulting string is the store path of the newly created
> store object.
https://nix.dev/manual/nix/2.28/language/string-interpolation#interpolated-expression
Users can specify which systems to use by having our `systems` input
follow a different file or flake:
```nix
{
inputs = {
# Here we list systems in a local file
inputs.systems.url = "path:./systems.nix";
inputs.systems.flake = false;
inputs.nixvim.url = "github:nix-community/nixvim";
# Here we override the list of systems with only our own
inputs.nixvim.inputs.systems.follows = "systems";
# ...
};
outputs = inputs: {
# ...
};
}
```
Alternatively, instead of users listing systems in a local file, they
can use an external flake, e.g.:
- github:nix-systems/default
- Exposes aarch64 and x86_64 for linux and darwin
- github:nix-systems/default-linux
- Exposes aarch64 and x86_64 for linux
- github:nix-systems/default-darwin
- Exposes aarch64 and x86_64 for darwin
- github:nix-systems/aarch64-darwin
- github:nix-systems/aarch64-linux
- github:nix-systems/x86_64-darwin
- github:nix-systems/x86_64-linux
See https://github.com/nix-systems/nix-systems
Update the extraConfig function to access settings through opts parameter
instead of direct import. Also remove the unused options import for cleaner code.
Add a new `keymaps` option to the lz-n plugin that allows users to define
keymaps that use lz.n's keymap(<plugin>).set functionality. This enables
users to create keymaps that lazy-load plugins when specific keys are pressed,
using the familiar vim.keymap.set() API style.
The implementation:
- Adds a new `keymaps` option using mkMapOptionSubmodule with a custom plugin property
- Exposes a simple and consistent interface for configuring lazy-loaded keymaps
- Processes these keymaps to generate corresponding Lua code with require('lz.n').keymap().set()
- Cleanly separates plugin specs from keymap definitions while preserving their relationship
Previously I said we alias the definitions instead of the value to allow
`mkOrder` to work correctly. That is incorrect, as order-priorities are
already sorted in `<opt>.definitions`.
The actual reason to use the definitions instead of the final value is
to avoid inf-recursion. The "from" option's `apply` function would read
the "to" option's value, which is defined based on the "from" option's
value, which is set by the "from" option's apply function...
For a one-way binding, `mkDerivedConfig` is best. For a two-way binding,
`mkAliasAndWrapDefsWithPriority` is necessary.
