Introduce `_mk-source-plugin.nix`, which returns a module handling a
specific none-ls source plugin.
This wasn't possible previously due to IFD conflicting with evaluating
module imports.
Adjusted the test to use the `options` provided via module args, and
cleaned up some stuff allowing "unpackaged" sources to not be listed
again in the test file.
The plugin's default is not compatible with nix, because it ends up in
the read-only /nix/store.
Set our default to the one used in their upcoming "1.0" version.
- Rename workflow to simply "update"
- Drop the DeterminateSystems/update-flake-lock action
- Instead use `nix flake update --commit-lock-file`
- Also use `generate-files`'s `--commit` option
- Use peter-evans/create-pull-request to open a PR
Added support for the plugin's "advanced" config settings.
Removed the enum restriction and prefix concatenation, allowing anything
to be passed through, including raw lua: fixes#1675
The theme list is now much shorter and is included directly in the option
description.
Some general cleanup, in particular to `extraConfig` and `customColorschemeType`.
as this isn't used by consumers, they should be able to remove this
input via `inputs.nixvim.inputs.git-hooks.follows = ""`. it is
especially important here as `git-hooks` has a large amount of inputs
itself
Moved `extraFiles` from `modules/output.nix` into its own file `modules/files.nix`.
Users should now assign text to a `text` attribute, however they could
also assign a file path to a `source` attribute instead.
The old method of directly assigning a string still works, and is
coerced to the new type along with a deprecation warning.
Based on `types.coerceTo`, which is like `types.either` but coerces the
left-hand type into the right-hand type.
`transitionType` only shows the right-hand type in its description and
also prints a warning when the left-hand type is used.
Co-authored-by: Silvan Mosberger <contact@infinisil.com>
Replaced the `isDocs` specialArg added in #1807 with an internal module
option.
We should only use `specialArgs` when absolutely necessary, a module or
`_module.args` is preferred, but those aren't available until `config`
is evaluated so they can't be used for `imports`.
The main problem with `specialArgs` is it makes our modules less
portable.
Luckily that shouldn't be an issue for these context flags.
