docs: rename all instances of `neovim-flake` to `nvf`
This commit is contained in:
parent
ebe0d6c960
commit
227f80ac9d
|
|
@ -86,12 +86,12 @@
|
|||
|
||||
transformOptions = opt:
|
||||
recursiveUpdate opt {
|
||||
# Clean up declaration sites to not refer to the neovim-flakee
|
||||
# Clean up declaration sites to not refer to the nvf
|
||||
# source tree.
|
||||
declarations = map (decl:
|
||||
if hasPrefix nvimPath (toString decl)
|
||||
then
|
||||
githubDeclaration "notashelf" "neovim-flake"
|
||||
githubDeclaration "notashelf" "nvf"
|
||||
(removePrefix "/" (removePrefix nvimPath (toString decl)))
|
||||
else if decl == "lib/modules.nix"
|
||||
then
|
||||
|
|
@ -105,7 +105,7 @@
|
|||
// builtins.removeAttrs args ["modules" "includeModuleSystemOptions"]);
|
||||
|
||||
nvimModuleDocs = buildOptionsDocs {
|
||||
variablelistId = "neovim-flake-options";
|
||||
variablelistId = "nvf-options";
|
||||
|
||||
modules =
|
||||
import ../modules/modules.nix {
|
||||
|
|
@ -117,7 +117,7 @@
|
|||
|
||||
# Generate the `man home-configuration.nix` package
|
||||
nvf-configuration-manual =
|
||||
pkgs.runCommand "neovim-flake-reference-manpage" {
|
||||
pkgs.runCommand "nvf-reference-manpage" {
|
||||
nativeBuildInputs = [pkgs.buildPackages.installShellFiles pkgs.nixos-render-docs];
|
||||
allowedReferences = ["out"];
|
||||
} ''
|
||||
|
|
@ -130,21 +130,21 @@
|
|||
--header ${./man/header.5} \
|
||||
--footer ${./man/footer.5} \
|
||||
${nvimModuleDocs.optionsJSON}/share/doc/nixos/options.json \
|
||||
$out/share/man/man5/neovim-flake.5
|
||||
$out/share/man/man5/nvf.5
|
||||
|
||||
cp ${./man/neovim-flake.1} $out/share/man/man1/neovim-flake.1
|
||||
cp ${./man/nvf.1} $out/share/man/man1/nvf.1
|
||||
'';
|
||||
|
||||
# Generate the HTML manual pages
|
||||
neovim-flake-manual = pkgs.callPackage ./manual.nix {
|
||||
nvf-manual = pkgs.callPackage ./manual.nix {
|
||||
inherit revision manpageUrls;
|
||||
outputPath = "share/doc/neovim-flake";
|
||||
outputPath = "share/doc/nvf";
|
||||
options = {
|
||||
neovim-flake = nvimModuleDocs.optionsJSON;
|
||||
nvf = nvimModuleDocs.optionsJSON;
|
||||
};
|
||||
};
|
||||
|
||||
html = neovim-flake-manual;
|
||||
html = nvf-manual;
|
||||
htmlOpenTool = pkgs.callPackage ./html-open-tool.nix {} {inherit html;};
|
||||
in {
|
||||
inherit (inputs) nmd;
|
||||
|
|
@ -154,16 +154,16 @@ in {
|
|||
# `nixosOptionsDoc` is more customizable.
|
||||
json =
|
||||
pkgs.runCommand "options.json" {
|
||||
meta.description = "List of neovim-flake options in JSON format";
|
||||
meta.description = "List of nvf options in JSON format";
|
||||
} ''
|
||||
mkdir -p $out/{share/doc,nix-support}
|
||||
cp -a ${nvimModuleDocs.optionsJSON}/share/doc/nixos $out/share/doc/neovim-flake
|
||||
cp -a ${nvimModuleDocs.optionsJSON}/share/doc/nixos $out/share/doc/nvf
|
||||
substitute \
|
||||
${nvimModuleDocs.optionsJSON}/nix-support/hydra-build-products \
|
||||
$out/nix-support/hydra-build-products \
|
||||
--replace \
|
||||
'${nvimModuleDocs.optionsJSON}/share/doc/nixos' \
|
||||
"$out/share/doc/neovim-flake"
|
||||
"$out/share/doc/nvf"
|
||||
'';
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
symlinkJoin,
|
||||
}: {
|
||||
html,
|
||||
pathName ? "neovim-flake",
|
||||
pathName ? "nvf",
|
||||
projectName ? pathName,
|
||||
name ? "${pathName}-help",
|
||||
}: let
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
.SH "AUTHORS"
|
||||
.PP
|
||||
neovim-flake contributors
|
||||
nvf contributors
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.TH "neovim-flake" "5" "01/01/1980" "neovim-flake"
|
||||
.TH "nvf" "5" "01/01/1980" "nvf"
|
||||
.\" disable hyphenation
|
||||
.nh
|
||||
.\" disable justification (adjust text to left margin only)
|
||||
|
|
@ -6,8 +6,8 @@
|
|||
.\" enable line breaks after slashes
|
||||
.cflags 4 /
|
||||
.SH "NAME"
|
||||
neovim-flake configuration specification
|
||||
nvf configuration specification
|
||||
.SH "OPTIONS"
|
||||
.PP
|
||||
You can use the following options to configure neovim-flake:
|
||||
You can use the following options to configure nvf:
|
||||
.PP
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.Dd January 1, 1980
|
||||
.Dt neovim-flake 1
|
||||
.Os neovim-flake
|
||||
.Dt nvf 1
|
||||
.Os nvf
|
||||
.\" disable hyphenation
|
||||
.nh
|
||||
.\" disable justification (adjust text to left margin only)
|
||||
|
|
@ -8,8 +8,8 @@
|
|||
.\" enable line breaks after slashes
|
||||
.cflags 4 /
|
||||
.Sh NAME
|
||||
.Nm neovim-flake
|
||||
.Nd A highly modular, extensible and distro-agnostic Neovim distribution for Nix/NixOS.
|
||||
.Nm nvf
|
||||
.Nd A highly modular, extensible and distro-agnostic Neovim configuration framework for Nix/NixOS.
|
||||
.
|
||||
.Sh BUGS
|
||||
.Pp
|
||||
|
|
@ -18,16 +18,16 @@ Please report any bugs that you might encounter on the
|
|||
|
||||
.Sh SEE ALSO
|
||||
.Pp
|
||||
\fBneovim-flake\fR(5)
|
||||
\fBnvf\fR(5)
|
||||
|
||||
.Sh AUTHOR
|
||||
.Pp
|
||||
\fBneovim-flake contributors\fR
|
||||
\fBnvf contributors\fR
|
||||
.RS 4
|
||||
Author.
|
||||
.RE
|
||||
|
||||
.Sh COPYRIGHT
|
||||
.br
|
||||
Copyright \(co 2023\(en2024 neovim-flake contributors
|
||||
Copyright \(co 2023\(en2024 nvf contributors
|
||||
.br
|
||||
|
|
@ -8,13 +8,13 @@
|
|||
manpageUrls,
|
||||
revision,
|
||||
options,
|
||||
outputPath ? "share/doc/neovim-flake",
|
||||
outputPath ? "share/doc/nvf",
|
||||
}:
|
||||
stdenvNoCC.mkDerivation {
|
||||
name = "neovim-flake-manual";
|
||||
name = "nvf-manual";
|
||||
src = builtins.path {
|
||||
path = lib.sourceFilesBySuffices ./manual [".md"];
|
||||
name = "neovim-flake-manual";
|
||||
name = "nvf-manual";
|
||||
};
|
||||
|
||||
nativeBuildInputs = [nixos-render-docs];
|
||||
|
|
@ -31,7 +31,7 @@ stdenvNoCC.mkDerivation {
|
|||
substituteInPlace ./options.md \
|
||||
--subst-var-by \
|
||||
OPTIONS_JSON \
|
||||
${options.neovim-flake}/share/doc/nixos/options.json
|
||||
${options.nvf}/share/doc/nixos/options.json
|
||||
|
||||
substituteInPlace ./manual.md \
|
||||
--subst-var-by \
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Configuring neovim-flake {#ch-configuring}
|
||||
# Configuring nvf {#ch-configuring}
|
||||
|
||||
```{=include=} chapters
|
||||
configuring/custom-package.md
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
# Custom Neovim Package {#ch-custom-package}
|
||||
|
||||
As of v0.5, you may now specify the neovim package that will be wrapped with your configuration. This is done with the `vim.package` option.
|
||||
As of v0.5, you may now specify the Neovim package that will be wrapped with
|
||||
your configuration. This is done with the `vim.package` option.
|
||||
|
||||
```nix
|
||||
{inputs, pkgs, ...}: {
|
||||
|
|
@ -9,8 +10,9 @@ As of v0.5, you may now specify the neovim package that will be wrapped with you
|
|||
}
|
||||
```
|
||||
|
||||
The neovim-nightly-overlay always exposes an unwrapped package. If using a different source, you are highly
|
||||
recommended to get an "unwrapped" version of the neovim package, similar to `neovim-unwrapped` in nixpkgs.
|
||||
The neovim-nightly-overlay always exposes an unwrapped package. If using a
|
||||
different source, you are highly recommended to get an "unwrapped" version of
|
||||
the neovim package, similar to `neovim-unwrapped` in nixpkgs.
|
||||
|
||||
```nix
|
||||
{ pkgs, ...}: {
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
# Custom Plugins {#ch-custom-plugins}
|
||||
|
||||
Neovim-flake, by default, exposes a wide variety of plugins as module options
|
||||
for your convience and bundles necessary dependencies into neovim-flake's
|
||||
runtime. In case a plugin is not available in neovim-flake, you may consider
|
||||
making a pull request to neovim-flake to include it as a module or you may add
|
||||
it to your configuration locally.
|
||||
**nvf**, by default, exposes a wide variety of plugins as module options
|
||||
for your convience and bundles necessary dependencies into **nvf**'s runtime.
|
||||
In case a plugin is not available in **nvf**, you may consider making a pull
|
||||
request to **nvf** to include it as a module or you may add it to your
|
||||
configuration locally.
|
||||
|
||||
## Adding Plugins {#ch-adding-plugins}
|
||||
|
||||
There are multiple ways of adding custom plugins to your neovim-flake
|
||||
configuration.
|
||||
There are multiple ways of adding custom plugins to your **nvf** configuration.
|
||||
|
||||
You can use custom plugins, before they are implemented in the flake. To add a
|
||||
plugin, you need to add it to your config's `vim.startPlugins` array.
|
||||
plugin to the runtime, you need to add it to the `vim.startPlugins` list in
|
||||
your configuration.
|
||||
|
||||
Adding a plugin to `startPlugins` will not allow you to configure the plugin
|
||||
that you have addeed, but neovim-flake provides multiple way of configuring any
|
||||
that you have adeed, but **nvf** provides multiple way of configuring any
|
||||
custom plugins that you might have added to your configuration.
|
||||
|
||||
```{=include=} sections
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
# Configuring {#sec-configuring-plugins}
|
||||
|
||||
Just making the plugin to your neovim configuration available might not always be enough.
|
||||
In that case, you can write custom vimscript or lua config, using `config.vim.configRC` or `config.vim.luaConfigRC`
|
||||
respectively. These options are attribute sets, and you need to give the configuration you're adding some name, like this:
|
||||
Just making the plugin to your Neovim configuration available might not always
|
||||
be enough. In that case, you can write custom vimscript or lua config, using
|
||||
either `config.vim.configRC` or `config.vim.luaConfigRC` respectively. Both of
|
||||
these options are attribute sets, and you need to give the configuration you're
|
||||
adding some name, like this:
|
||||
|
||||
```nix
|
||||
{
|
||||
|
|
@ -13,11 +15,12 @@ respectively. These options are attribute sets, and you need to give the configu
|
|||
```
|
||||
|
||||
:::{.note}
|
||||
If your configuration needs to be put in a specific place in the config, you can use functions from
|
||||
`inputs.neovim-flake.lib.nvim.dag` to order it.
|
||||
Refer to https://github.com/nix-community/home-manager/blob/master/modules/lib/dag.nix to find out more about
|
||||
the DAG system.
|
||||
If your configuration needs to be put in a specific place in the config, you
|
||||
can use functions from `inputs.nvf.lib.nvim.dag` to order it. Refer to
|
||||
https://github.com/nix-community/home-manager/blob/master/modules/lib/dag.nix
|
||||
to find out more about the DAG system.
|
||||
:::
|
||||
|
||||
Also, if you successfully made your plugin work, please make a PR to add it to the flake, or open an issue
|
||||
with your findings so that we can make it available for everyone easily.
|
||||
If you successfully made your plugin work, please feel free to create a PR to
|
||||
add it to **nvf** or open an issue with your findings so that we can make it
|
||||
available for everyone easily.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# New Method {#sec-new-method}
|
||||
|
||||
As of version **0.5**, we have a more extensive API for configuring plugins, under `vim.extraPlugins`.
|
||||
|
||||
Instead of using DAGs exposed by the library, you may use the extra plugin module as follows:
|
||||
As of version **0.5**, we have a more extensive API for configuring plugins,
|
||||
under `vim.extraPlugins`. Instead of using DAGs exposed by the library, you may
|
||||
use the extra plugin module as follows:
|
||||
|
||||
```nix
|
||||
{
|
||||
|
|
|
|||
|
|
@ -1,12 +1,14 @@
|
|||
# Old Method {#sec-old-method}
|
||||
|
||||
Prior to version 0.5, the method of adding new plugins was adding the plugin package to `vim.startPlugins` and add
|
||||
its configuration as a DAG under `vim.configRC` or `vim.luaConfigRC`. Users who have not yet updated to 0.5, or prefer
|
||||
a more hands-on approach may use the old method where the load order of the plugins is determined by DAGs.
|
||||
Prior to version 0.5, the method of adding new plugins was adding the plugin
|
||||
package to `vim.startPlugins` and add its configuration as a DAG under one of
|
||||
`vim.configRC` or `vim.luaConfigRC`. Users who have not yet updated to 0.5, or
|
||||
prefer a more hands-on approach may use the old method where the load order of
|
||||
the plugins is determined by DAGs.
|
||||
|
||||
## Adding plugins {#sec-adding-plugins}
|
||||
|
||||
To add a plugin to neovim-flake's runtime, you may add it
|
||||
To add a plugin to **nvf**'s runtime, you may add it
|
||||
|
||||
```nix
|
||||
{pkgs, ...}: {
|
||||
|
|
@ -16,13 +18,13 @@ To add a plugin to neovim-flake's runtime, you may add it
|
|||
}
|
||||
```
|
||||
|
||||
And to configure the added plugin, you can use the `luaConfigRC` option to provide configuration
|
||||
as a DAG using the neovim-flake extended library.
|
||||
And to configure the added plugin, you can use the `luaConfigRC` option to
|
||||
provide configuration as a DAG using the **nvf** extended library.
|
||||
|
||||
```nix
|
||||
{inputs, ...}: let
|
||||
# assuming you have an input called neovim-flake pointing at the neovim-flake repo
|
||||
inherit (inputs.neovim-flake.lib.nvim.dag) entryAnywhere;
|
||||
# assuming you have an input called nvf pointing at the nvf repository
|
||||
inherit (inputs.nvf.lib.nvim.dag) entryAnywhere;
|
||||
in {
|
||||
vim.luaConfigRC.aerial-nvim= entryAnywhere ''
|
||||
require('aerial').setup {
|
||||
|
|
|
|||
|
|
@ -1,13 +1,17 @@
|
|||
# Using DAGs {#ch-using-dags}
|
||||
|
||||
We conform to the NixOS options types for the most part, however, a noteworthy addition
|
||||
for certain options is the [**DAG (Directed acyclic graph)**](https://en.wikipedia.org/wiki/Directed_acyclic_graph)
|
||||
type which is borrowed from home-manager's extended library. This type is most used for
|
||||
topologically sorting strings. The DAG type allows the attribute set entries to express dependency
|
||||
relations among themselves. This can, for example, be used to control the order of configuration
|
||||
sections in your `configRC` or `luaConfigRC`.
|
||||
We conform to the NixOS options types for the most part, however, a noteworthy
|
||||
addition for certain options is the [**DAG
|
||||
(Directed acyclic graph)**](https://en.wikipedia.org/wiki/Directed_acyclic_graph)
|
||||
type which is borrowed from home-manager's extended library. This type is most
|
||||
used for topologically sorting strings. The DAG type allows the attribute set
|
||||
entries to express dependency relations among themselves. This can, for
|
||||
example, be used to control the order of configuration sections in your
|
||||
`configRC` or `luaConfigRC`.
|
||||
|
||||
The below section, mostly taken from the [home-manager manual](https://raw.githubusercontent.com/nix-community/home-manager/master/docs/manual/writing-modules/types.md) explains the overal usage logic of the DAG typee
|
||||
The below section, mostly taken from the [home-manager
|
||||
manual](https://raw.githubusercontent.com/nix-community/home-manager/master/docs/manual/writing-modules/types.md)
|
||||
explains in more detail the overall usage logic of the DAG type.
|
||||
|
||||
## entryAnywhere {#sec-types-dag-entryAnywhere}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
# Language Support {#ch-languages}
|
||||
|
||||
Language specific support means there is a combination of language specific plugins, `treesitter` support, `nvim-lspconfig` language servers, and `null-ls`
|
||||
integration. This gets you capabilities ranging from autocompletion to formatting to diagnostics. The following languages have sections under the `vim.languages`
|
||||
Language specific support means there is a combination of language specific
|
||||
plugins, `treesitter` support, `nvim-lspconfig` language servers, and `null-ls`
|
||||
integration. This gets you capabilities ranging from autocompletion to formatting
|
||||
to diagnostics. The following languages have sections under the `vim.languages`
|
||||
attribute.
|
||||
|
||||
- Rust: [vim.languages.rust.enable](#opt-vim.languages.rust.enable)
|
||||
|
|
|
|||
|
|
@ -1,15 +1,17 @@
|
|||
# LSP Custom Packages/Command {#sec-languages-custom-lsp-packages}
|
||||
|
||||
In any of the `opt.languages.<language>.lsp.package` options you can provide your own LSP package, or provide
|
||||
the command to launch the language server, as a list of strings.
|
||||
|
||||
You can use this to skip automatic installation of a language server, and instead
|
||||
use the one found in your `$PATH` during runtime, for example:
|
||||
In any of the `opt.languages.<language>.lsp.package` options you can provide
|
||||
your own LSP package, or provide the command to launch the language server, as
|
||||
a list of strings. You can use this to skip automatic installation of a language
|
||||
server, and instead use the one found in your `$PATH` during runtime, for
|
||||
example:
|
||||
|
||||
```nix
|
||||
vim.languages.java = {
|
||||
lsp = {
|
||||
enable = true;
|
||||
# this expects jdt-language-server to be in your PATH
|
||||
# or in `vim.extraPackages`
|
||||
package = ["jdt-language-server" "-data" "~/.cache/jdtls/workspace"];
|
||||
};
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,10 +1,9 @@
|
|||
# Default Configs {#ch-default-configs}
|
||||
|
||||
While you can configure neovim-flake yourself using the builder, you can also use the pre-built configs that are available.
|
||||
While you can configure **nvf** yourself using the builder, you can also use the pre-built configs that are available.
|
||||
Here are a few default configurations you can use.
|
||||
|
||||
```{=include=} chapters
|
||||
default-configs/maximal.md
|
||||
default-configs/nix.md
|
||||
default-configs/tidal.md
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
# Maximal {#sec-default-maximal}
|
||||
|
||||
```bash
|
||||
$ nix shell github:notashelf/neovim-flake#maximal test.nix
|
||||
$ nix shell github:notashelf/nvf#maximal test.nix
|
||||
```
|
||||
|
||||
It is the same fully configured neovim as with the [Nix](#sec-default-nix) config, but with every supported language enabled.
|
||||
|
||||
:::{.note}
|
||||
|
||||
Running the maximal config will download _a lot_ of packages as it is downloading language servers, formatters, and more.
|
||||
It is the same fully configured Neovim as with the [Nix](#sec-default-nix)
|
||||
configuration, but with every supported language enabled.
|
||||
|
||||
::: {.note}
|
||||
Running the maximal config will download _a lot_ of packages as it is
|
||||
downloading language servers, formatters, and more.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
# Nix {#sec-default-nix}
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/neovim-flake#nix test.nix
|
||||
$ nix run github:notashelf/nvf#nix test.nix
|
||||
```
|
||||
|
||||
Enables all the of neovim plugins, with language support for specifically Nix. This lets you see what a fully configured neovim setup looks like without downloading a whole bunch of language servers and associated tools.
|
||||
Enables all the of Neovim plugins, with language support for specifically Nix.
|
||||
This lets you see what a fully configured neovim setup looks like without
|
||||
downloading a whole bunch of language servers and associated tools.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
# Tidal Cycles {#sec-default-tidal}
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/neovim-flake#tidal file.tidal
|
||||
```
|
||||
|
||||
Utilizing [vim-tidal](https://github.com/tidalcycles/vim-tidal) and mitchmindtree's fantastic
|
||||
[tidalcycles.nix](https://github.com/mitchmindtree/tidalcycles.nix) start playing with tidal cycles in a single command.
|
||||
|
||||
In your tidal file, type a cycle e.g. `d1 $ s "drum"` and then press _ctrl+enter_. Super collider with superdirt, and a
|
||||
modified GHCI with tidal will start up and begin playing. Note, you need jack enabled on your system. If you are using
|
||||
pipewire, its as easy as setting `services.pipewire.jack.enable = true` in your configuration.
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
# Hacking neovim-flake {#ch-hacking}
|
||||
# Hacking nvf {#ch-hacking}
|
||||
|
||||
neovim-flake is designed for developers as much as it is for the end user. I would like any potential contributor
|
||||
**nvf** is designed for developers as much as it is for the end user. I would like any potential contributor
|
||||
to be able to propagate their desired changes into the repository without the extra effort. As such, below are guides
|
||||
(and guidelines) to streamline the contribution process and ensure that your valuable input seamlessly integrates
|
||||
into neovim-flake's development without leaving question marks in your head.
|
||||
into **nvf**'s development without leaving question marks in your head.
|
||||
|
||||
This section is mainly directed towards those who wish to contribute code into neovim-flake. If you wish to instead
|
||||
This section is mainly directed towards those who wish to contribute code into **nvf**. If you wish to instead
|
||||
report a bug or discuss a potential feature implementation, first look among the
|
||||
already [open issues](https://github.com/notashelf/neovim-flake/issues) and if no matching issue exists you may open
|
||||
a [new issue](https://github.com/notashelf/neovim-flake/issues/new) and describe your problem/request. While creating an
|
||||
already [open issues](https://github.com/notashelf/nvf/issues) and if no matching issue exists you may open
|
||||
a [new issue](https://github.com/notashelf/nvf/issues/new) and describe your problem/request. While creating an
|
||||
issue, please try to include as much information as you can, ideally also include relevant context in which an issue
|
||||
occurs or a feature should be implemented.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Adding Plugins {#sec-additional-plugins}
|
||||
|
||||
To add a new neovim plugin, first add the source url in the inputs section of `flake.nix`
|
||||
To add a new Neovim plugin, first add the source url in the inputs section of `flake.nix`
|
||||
with the prefix `plugin-`
|
||||
|
||||
```nix
|
||||
|
|
@ -17,7 +17,7 @@ with the prefix `plugin-`
|
|||
}
|
||||
```
|
||||
|
||||
The addition of the `plugin-` prefix will allow neovim-flake to autodiscover the
|
||||
The addition of the `plugin-` prefix will allow **nvf** to autodiscover the
|
||||
input from the flake inputs automatically, allowing you to refer to it in areas
|
||||
that require a very specific plugin type as defined in `lib/types/plugins.nix`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,16 @@
|
|||
# Getting Started {#sec-contrib-getting-started}
|
||||
|
||||
You naturally would like to start by forking the repository. If you are new to git, have a look at GitHub's
|
||||
[Fork a repo guide](https://help.github.com/articles/fork-a-repo/) for instructions on how you can do this. Once you have a fork of neovim-flake
|
||||
you should create a branch starting at the most recent `main` branch.
|
||||
Give your branch a reasonably descriptive name, suffixed by its type - i.e `feature/debugger` or `fix/pesky-bug`.
|
||||
You, naturally, would like to start by forking the repository to get started. If
|
||||
you are new to Git and GitHub, do have a look at GitHub's [Fork a repo guide](https://help.github.com/articles/fork-a-repo/)
|
||||
for instructions on how you can do this. Once you have a fork of **nvf**, you
|
||||
should create a separate branch based on the msot recent `main` branch. Give
|
||||
your branch a reasonably descriptive name (e.g. `feature/debugger` or
|
||||
`fix/pesky-bug`) and you are ready to work on your changes
|
||||
|
||||
Implement your changes and commit them to the newly created branch and when you are happy with the result and positive
|
||||
that it fulfills [Guidelines](#sec-guidelines). Once you are confident everything is in order, push the branch to GitHub and
|
||||
[create a pull request](https://help.github.com/articles/creating-a-pull-request), following the template that you will be prompted to fill.
|
||||
Implement your changes and commit them to the newly created branch and when you
|
||||
are happy with the result, and positive that it fullfills our [Contributing
|
||||
Guidelines](#sec-guidelines), push the branch to GitHub and [create a pull
|
||||
request](https://help.github.com/articles/creating-a-pull-request). The default
|
||||
pull request template available on the **nvf** repository will guide you through
|
||||
the rest of the process, and we'll gently nudge you in the correct direction if
|
||||
there are any mistakes.
|
||||
|
|
|
|||
|
|
@ -1,55 +1,65 @@
|
|||
# Guidelines {#sec-guidelines}
|
||||
|
||||
If your contribution tightly follows the guidelines, then there is a good chance it will be merged without too much
|
||||
trouble. Some of the guidelines will be strictly enforced, others will remain as gentle nudges towards the correct
|
||||
direction. As we have no automated system enforcing those guidelines, please try to double check your changes before
|
||||
making your pull request in order to avoid "faulty" code slipping by.
|
||||
If your contribution tightly follows the guidelines, then there is a good chance
|
||||
it will be merged without too much trouble. Some of the guidelines will be
|
||||
strictly enforced, others will remain as gentle nudges towards the correct
|
||||
direction. As we have no automated system enforcing those guidelines, please
|
||||
try to double check your changes before making your pull request in order to
|
||||
avoid "faulty" code slipping by.
|
||||
|
||||
If you are uncertain how these rules affect the change you would like to make then feel free to start a
|
||||
discussion in the [discussions tab](https://github.com/NotAShelf/neovim-flake/discussions) ideally (but not necessarily)
|
||||
before you start developing.
|
||||
If you are uncertain how these rules affect the change you would like to make
|
||||
then feel free to start a discussion in the [discussions tab](https://github.com/NotAShelf/nvf/discussions)
|
||||
ideally (but not necessarily) before you start developing.
|
||||
|
||||
## Adding Documentation {#sec-guidelines-documentation}
|
||||
|
||||
Most, if not all, changes warrant changes to the documentation. Module options should be documented with
|
||||
[Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup), albeit with exceptions.
|
||||
|
||||
:::{.note}
|
||||
|
||||
As of v0.5, neovim-flake is itself documented using full markdown in both module options and the manual. With
|
||||
v0.6, this manual has also been converted to markdown in full.
|
||||
Most, if not all, changes warrant changes to the documentation. Module options
|
||||
should be documented with [Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup),
|
||||
albeit with exceptions.
|
||||
|
||||
::: {.note}
|
||||
As of **v0.5**, **vf** is itself documented using full markdown in both module
|
||||
options and the manual. With **v0.6**, this manual has also been converted to
|
||||
markdown in full.
|
||||
:::
|
||||
|
||||
The HTML version of this manual containing both the module option descriptions and the documentation of neovim-flake
|
||||
(such as this page) can be generated and opened by typing the following in a shell within a clone of the
|
||||
neovim-flake Git repository:
|
||||
The HTML version of this manual containing both the module option descriptions
|
||||
and the documentation of **nvf** (such as this page) can be generated and
|
||||
opened by typing the following in a shell within a clone of the **nvf** Git
|
||||
repository:
|
||||
|
||||
```console
|
||||
$ nix build .#docs-html
|
||||
$ xdg-open $PWD/result/share/doc/neovim-flake/index.html
|
||||
$ xdg-open $PWD/result/share/doc/nvf/index.html
|
||||
```
|
||||
|
||||
## Formatting Code {#sec-guidelines-formatting}
|
||||
|
||||
Make sure your code is formatted as described in [code-style section](#sec-guidelines-code-style). To maintain consistency throughout
|
||||
the project you are encouraged to browse through existing code and adopt its style also in new code.
|
||||
Make sure your code is formatted as described in [code-style
|
||||
section](#sec-guidelines-code-style). To maintain consistency throughout the
|
||||
project you are encouraged to browse through existing code and adopt its style
|
||||
also in new code.
|
||||
|
||||
## Formatting Commits {#sec-guidelines-commit-message-style}
|
||||
|
||||
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a consistent commit message format as described
|
||||
in [commit style guidelines](#sec-guidelines-commit-style).
|
||||
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a
|
||||
consistent commit message format as described in [commit style
|
||||
guidelines](#sec-guidelines-commit-style).
|
||||
|
||||
## Commit Style {#sec-guidelines-commit-style}
|
||||
|
||||
The commits in your pull request should be reasonably self-contained. Which means each and every commit in
|
||||
a pull request should make sense both on its own and in general context. That is, a second commit should not resolve
|
||||
an issue that is introduced in an earlier commit. In particular, you will be asked to amend any commit that
|
||||
introduces syntax errors or similar problems even if they are fixed in a later commit.
|
||||
The commits in your pull request should be reasonably self-contained. Which
|
||||
means each and every commit in a pull request should make sense both on its
|
||||
own and in general context. That is, a second commit should not resolve an
|
||||
issue that is introduced in an earlier commit. In particular, you will be
|
||||
asked to amend any commit that introduces syntax errors or similar problems
|
||||
even if they are fixed in a later commit.
|
||||
|
||||
The commit messages should follow the [seven rules](https://chris.beams.io/posts/git-commit/#seven-rule),
|
||||
except for "Capitalize the subject line". We also ask you to include the affected code component or module in
|
||||
the first line. A commit message ideally, but not necessarily, follow the given template from home-manager's own documentation
|
||||
The commit messages should follow the [seven
|
||||
rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
|
||||
"Capitalize the subject line". We also ask you to include the affected code
|
||||
component or module in the first line. A commit message ideally, but not
|
||||
necessarily, follow the given template from home-manager's own documentation
|
||||
|
||||
```
|
||||
{component}: {description}
|
||||
|
|
@ -57,15 +67,18 @@ the first line. A commit message ideally, but not necessarily, follow the given
|
|||
{long description}
|
||||
```
|
||||
|
||||
where `{component}` refers to the code component (or module) your change affects, `{description}` is a very brief
|
||||
description of your change, and `{long description}` is an optional clarifying description. As a rare exception, if
|
||||
there is no clear component, or your change affects many components, then the `{component}` part is optional.
|
||||
See [example commit message](#sec-guidelines-ex-commit-message) for a commit message that fulfills these requirements.
|
||||
where `{component}` refers to the code component (or module) your change
|
||||
affects, `{description}` is a very brief description of your change, and
|
||||
`{long description}` is an optional clarifying description. As a rare
|
||||
exception, if there is no clear component, or your change affects many
|
||||
components, then the `{component}` part is optional. See [example commit
|
||||
message](#sec-guidelines-ex-commit-message) for a commit message that
|
||||
fulfills these requirements.
|
||||
|
||||
## Example Commit {#sec-guidelines-ex-commit-message}
|
||||
|
||||
The commit [69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
|
||||
in home-manager contains the commit message
|
||||
in home-manager contains the following commit message.
|
||||
|
||||
```
|
||||
starship: allow running in Emacs if vterm is used
|
||||
|
|
@ -74,38 +87,43 @@ The vterm buffer is backed by libvterm and can handle Starship prompts
|
|||
without issues.
|
||||
```
|
||||
|
||||
Similarly, if you are contributing to neovim-flake, you would include the scope of the commit followed by
|
||||
the description
|
||||
Similarly, if you are contributing to **nvf**, you would include the scope of
|
||||
the commit followed by the description:
|
||||
|
||||
```
|
||||
languages/ruby: init module
|
||||
|
||||
Adds a language module for Ruby, and adds appropriate formatters and TS grammers
|
||||
Adds a language module for Ruby, adds appropriate formatters and Treesitter grammers
|
||||
```
|
||||
|
||||
Long description can be ommitted if the change is too simple to warrant it. A minor fix in spelling or a formatting
|
||||
change does not warrant long description, however, a module addition or removal does as you would like to provide the
|
||||
relevant context, e.g. the reasoning behind it, for your commit.
|
||||
Long description can be ommitted if the change is too simple to warrant it. A
|
||||
minor fix in spelling or a formatting change does not warrant long description,
|
||||
however, a module addition or removal does as you would like to provide the
|
||||
relevant context, i.e. the reasoning behind it, for your commit.
|
||||
|
||||
Finally, when adding a new module, say `modules/foo.nix`, we use the fixed commit format `foo: add module`.
|
||||
You can, of course, still include a long description if you wish.
|
||||
Finally, when adding a new module, say `modules/foo.nix`, we use the fixed
|
||||
commit format `foo: add module`. You can, of course, still include a long
|
||||
description if you wish.
|
||||
|
||||
In case of nested modules, i.e `modules/languages/java.nix` you are recommended to contain the parent as well - for
|
||||
example `languages/java: some major change`.
|
||||
In case of nested modules, i.e `modules/languages/java.nix` you are recommended
|
||||
to contain the parent as well - for example `languages/java: some major change`.
|
||||
|
||||
## Code Style {#sec-guidelines-code-style}
|
||||
|
||||
**Treewide**
|
||||
Keep lines at a reasonable width, ideally 80 characters or less. This also applies to string literals and module
|
||||
descriptions and documentation.
|
||||
### Treewide
|
||||
|
||||
**Nix**
|
||||
neovim-flake is formatted by the [alejandra](https://github.com/kamadorueda/alejandra) tool and the formatting is checked in the pull
|
||||
request and push workflows. Run the `nix fmt` command inside the project repository before submitting your
|
||||
pull request.
|
||||
Keep lines at a reasonable width, ideally 80 characters or less. This also applies
|
||||
to string literals and module descriptions and documentation.
|
||||
|
||||
While Alejandra is mostly opinionated on how code looks after formatting, certain changes are done at the
|
||||
user's discretion based on how the original code was structured.
|
||||
### Nix
|
||||
|
||||
**nvf** is formatted by the [alejandra](https://github.com/kamadorueda/alejandra)
|
||||
tool and the formatting is checked in the pull request and push workflows. Run the
|
||||
`nix fmt` command inside the project repository before submitting your pull request.
|
||||
|
||||
While Alejandra is mostly opinionated on how code looks after formatting,
|
||||
certain changes are done at the user's discretion based on how the original
|
||||
code was structured.
|
||||
|
||||
Please use one line code for attribute sets that contain only one subset.
|
||||
For example:
|
||||
|
|
@ -128,8 +146,8 @@ module = {
|
|||
}
|
||||
```
|
||||
|
||||
If you move a line down after the merge operator, Alejandra will automatically unfold the whole merged attrset
|
||||
for you, which we **do not** want.
|
||||
If you move a line down after the merge operator, Alejandra will automatically
|
||||
unfold the whole merged attrset for you, which we **do not** want.
|
||||
|
||||
```nix
|
||||
module = {
|
||||
|
|
@ -139,13 +157,12 @@ module = {
|
|||
}
|
||||
```
|
||||
|
||||
For lists, it is mostly up to your own discretion how you want to format them, but please try to unfold lists if
|
||||
they contain multiple items and especially if they are to include comments.
|
||||
For lists, it is mostly up to your own discretion how you want to format them,
|
||||
but please try to unfold lists if they contain multiple items and especially
|
||||
if they are to include comments.
|
||||
|
||||
```nix
|
||||
|
||||
# this is ok
|
||||
|
||||
acceptableList = [
|
||||
item1 # comment
|
||||
item2
|
||||
|
|
@ -157,10 +174,12 @@ acceptableList = [
|
|||
listToBeAvoided = [item1 item2 /* comment */ item3 item4];
|
||||
|
||||
# this is ok
|
||||
acceptableList = [item1];
|
||||
acceptableList = [item1 item2];
|
||||
|
||||
# this is not ok
|
||||
listToBeAvoided = [
|
||||
# this is also ok if the list is expected to contain more elements
|
||||
acceptableList= [
|
||||
item1
|
||||
item2
|
||||
# more items if needed...
|
||||
];
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
# Keybinds {#sec-keybinds}
|
||||
|
||||
As of 0.4, there exists an API for writing your own keybinds and a couple of useful utility functions are available in
|
||||
the [extended standard library](https://github.com/NotAShelf/neovim-flake/tree/main/lib). The following section contains
|
||||
a general overview to how you may utilize said functions.
|
||||
As of 0.4, there exists an API for writing your own keybinds and a couple of
|
||||
useful utility functions are available in the [extended standard
|
||||
library](https://github.com/NotAShelf/nvf/tree/main/lib). The following
|
||||
section contains a general overview to how you may utilize said functions.
|
||||
|
||||
## Custom Key Mappings Support for a Plugin {#sec-custom-key-mappings}
|
||||
|
||||
|
|
@ -36,44 +37,58 @@ An example, simple keybinding, can look like this:
|
|||
```
|
||||
|
||||
There are many settings available in the options. Please refer to the
|
||||
[documentation](https://notashelf.github.io/neovim-flake/options.html#opt-vim.maps.command._name_.action)
|
||||
[documentation](https://notashelf.github.io/nvf/options.html#opt-vim.maps.command._name_.action)
|
||||
to see a list of them.
|
||||
|
||||
`neovim-flake` provides a list of helper commands, so that you don't have to write the mapping attribute sets every
|
||||
time:
|
||||
**nvf** provides a list of helper commands, so that you don't have to write the
|
||||
mapping attribute sets every time:
|
||||
|
||||
- `mkBinding = key: action: desc:` - makes a basic binding, with `silent` set to true.
|
||||
- `mkExprBinding = key: action: desc:` - makes an expression binding, with `lua`, `silent`, and `expr` set to true.
|
||||
- `mkLuaBinding = key: action: desc:` - makes an expression binding, with `lua`, and `silent` set to true.
|
||||
- `mkBinding = key: action: desc:` - makes a basic binding, with `silent` set
|
||||
to true.
|
||||
- `mkExprBinding = key: action: desc:` - makes an expression binding, with
|
||||
`lua`, `silent`, and `expr` set to true.
|
||||
- `mkLuaBinding = key: action: desc:` - makes an expression binding, with
|
||||
`lua`, and `silent` set to true.
|
||||
|
||||
Note that the Lua in these bindings is actual Lua, not pasted into a `:lua` command.
|
||||
Therefore, you either pass in a function like `require('someplugin').some_function`, without actually calling it,
|
||||
or you define your own function, like `function() require('someplugin').some_function() end`.
|
||||
Do note that the Lua in these bindings is actual Lua, and not pasted into a
|
||||
`:lua` command. Therefore, you should either pass in a function like
|
||||
`require('someplugin').some_function`, without actually calling it, or you
|
||||
should define your own functions, for example
|
||||
|
||||
Additionally, to not have to repeat the descriptions, there's another utility function with its own set of functions:
|
||||
```lua
|
||||
function()
|
||||
require('someplugin').some_function()
|
||||
end
|
||||
```
|
||||
|
||||
Utility function that takes two attrsets:
|
||||
Additionally, to not have to repeat the descriptions, there's another utility
|
||||
function with its own set of functions: Utility function that takes two
|
||||
attribute sets:
|
||||
|
||||
- `{ someKey = "some_value" }`
|
||||
- `{ someKey = { description = "Some Description"; }; }`
|
||||
|
||||
and merges them into `{ someKey = { value = "some_value"; description = "Some Description"; }; }`
|
||||
|
||||
```
|
||||
```nix
|
||||
addDescriptionsToMappings = actualMappings: mappingDefinitions:
|
||||
```
|
||||
|
||||
This function can be used in combination with the same `mkBinding` functions as above, except they only take two
|
||||
arguments - `binding` and `action`, and have different names:
|
||||
This function can be used in combination with the same `mkBinding` functions as
|
||||
above, except they only take two arguments - `binding` and `action`, and have
|
||||
different names:
|
||||
|
||||
- `mkSetBinding = binding: action:` - makes a basic binding, with `silent` set to true.
|
||||
- `mkSetExprBinding = binding: action:` - makes an expression binding, with `lua`, `silent`, and `expr` set to true.
|
||||
- `mkSetLuaBinding = binding: action:` - makes an expression binding, with `lua`, and `silent` set to true.
|
||||
- `mkSetBinding = binding: action:` - makes a basic binding, with `silent`
|
||||
set to true.
|
||||
- `mkSetExprBinding = binding: action:` - makes an expression binding, with
|
||||
`lua`, `silent`, and `expr` set to true.
|
||||
- `mkSetLuaBinding = binding: action:` - makes an expression binding, with
|
||||
`lua`, and `silent` set to true.
|
||||
|
||||
You can read the source code of some modules to see them in action, but their usage should look something like this:
|
||||
You can read the source code of some modules to see them in action, but their
|
||||
usage should look something like this:
|
||||
|
||||
```nix
|
||||
|
||||
# plugindefinition.nix
|
||||
{lib, ...}: with lib; {
|
||||
options.vim.plugin = {
|
||||
|
|
@ -96,15 +111,13 @@ You can read the source code of some modules to see them in action, but their us
|
|||
|
||||
};
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```nix
|
||||
|
||||
# config.nix
|
||||
{
|
||||
pkgs,
|
||||
config,
|
||||
pkgs,
|
||||
lib,
|
||||
...
|
||||
}:
|
||||
|
|
@ -158,9 +171,8 @@ in {
|
|||
|
||||
```
|
||||
|
||||
:::{.note}
|
||||
|
||||
If you have come across a plugin that has an API that doesn't seem to easily allow custom keybindings,
|
||||
don't be scared to implement a draft PR. We'll help you get it done.
|
||||
|
||||
::: {.note}
|
||||
If you have come across a plugin that has an API that doesn't seem to easily
|
||||
allow custom keybindings, don't be scared to implement a draft PR. We'll help
|
||||
you get it done.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -1,11 +1,15 @@
|
|||
# Testing Changes {#sec-testing-changes}
|
||||
|
||||
Once you have made your changes, you will need to test them throughly. If it is a module, add your module option to
|
||||
`configuration.nix` (located in the root of this project) inside `neovimConfiguration`. Enable it, and then run the
|
||||
maximal configuration with `nix run .#maximal -Lv` to check for build errors. If neovim opens in the current directory
|
||||
without any error messages (you can check the output of `:messages` inside neovim to see if there are any errors), then
|
||||
your changes are good to go. Open your pull request, and it will be reviewed as soon as posssible.
|
||||
Once you have made your changes, you will need to test them throughly. If it is
|
||||
a module, add your module option to `configuration.nix` (located in the root of
|
||||
this project) inside `neovimConfiguration`. Enable it, and then run the maximal
|
||||
configuration with `nix run .#maximal -Lv` to check for build errors. If neovim
|
||||
opens in the current directory without any error messages (you can check the
|
||||
output of `:messages` inside neovim to see if there are any errors), then your
|
||||
changes are good to go. Open your pull request, and it will be reviewed as soon
|
||||
as posssible.
|
||||
|
||||
If it is not a new module, but a change to an existing one, then make sure the module you have changed is enabled in the
|
||||
maximal configuration by editing `configuration.nix`, and then run it with `nix run .#maximal -Lv`. Same procedure as
|
||||
adding a new module will apply here.
|
||||
If it is not a new module, but a change to an existing one, then make sure the
|
||||
module you have changed is enabled in the maximal configuration by editing
|
||||
`configuration.nix`, and then run it with `nix run .#maximal -Lv`. Same procedure
|
||||
as adding a new module will apply here.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Installing neovim-flake {#ch-installation}
|
||||
# Installing nvf {#ch-installation}
|
||||
|
||||
There are multiple ways of installing neovim-flake on your system. You may either choose
|
||||
There are multiple ways of installing nvf on your system. You may either choose
|
||||
the standalone installation method, which does not depend on a module system and may
|
||||
be done on any system that has the Nix package manager or the appropriate modules
|
||||
for NixOS and home-manager as described in the [module installation section](#ch-module-installation)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Standalone Installation {#ch-standalone-installation}
|
||||
|
||||
It is possible to install neovim-flake without depending on NixOS or home-manager as the parent
|
||||
module system, using the `neovimConfiguration` function exposed by neovim-flake extended library.
|
||||
It is possible to install **nvf** without depending on NixOS or home-manager as the parent
|
||||
module system, using the `neovimConfiguration` function exposed by **nvf** extended library.
|
||||
It takes in the configuration as a module, and returns an attribute set as a result.
|
||||
|
||||
```nix
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
# Home Manager Module {#ch-hm-module}
|
||||
# Home-Manager Module {#ch-hm-module}
|
||||
|
||||
The Home Manager module allows us to customize the different `vim` options from inside the home-manager configuration
|
||||
and it is the preferred way of configuring neovim-flake, both on NixOS and non-NixOS systems.
|
||||
The home-manager module allows us to customize the different `vim` options from
|
||||
inside the home-manager configuration without having to call for the wrapper
|
||||
yourself. It is the recommended way to use **nvf** alongside the NixOS module
|
||||
depending on your needs.
|
||||
|
||||
To use it, we first add the input flake.
|
||||
|
||||
|
|
@ -9,8 +11,8 @@ To use it, we first add the input flake.
|
|||
{
|
||||
inputs = {
|
||||
obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
|
||||
neovim-flake = {
|
||||
url = "github:notashelf/neovim-flake";
|
||||
nvf = {
|
||||
url = "github:notashelf/nvf";
|
||||
# you can override input nixpkgs
|
||||
inputs.nixpkgs.follows = "nixpkgs";
|
||||
# you can also override individual plugins
|
||||
|
|
@ -25,41 +27,41 @@ Followed by importing the home-manager module somewhere in your configuration.
|
|||
|
||||
```nix
|
||||
{
|
||||
# assuming neovim-flake is in your inputs and inputs is in the argset
|
||||
imports = [ inputs.neovim-flake.homeManagerModules.default ];
|
||||
# assuming nvf is in your inputs and inputs is in the argset
|
||||
# see example below
|
||||
imports = [ inputs.nvf.homeManagerModules.default ];
|
||||
}
|
||||
```
|
||||
|
||||
An example installation for neovim-flake under standalone home-manager
|
||||
would look like this:
|
||||
## Example Installation {#sec-example-installation}
|
||||
|
||||
```nix
|
||||
{
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
home-manager.url = "github:nix-community/home-manager";
|
||||
neovim-flake.url = "github:notashelf/neovim-flake";
|
||||
nvf.url = "github:notashelf/nvf";
|
||||
};
|
||||
|
||||
outputs = { nixpkgs, home-manager, neovim-flake ... }: let
|
||||
outputs = { nixpkgs, home-manager, nvf, ... }: let
|
||||
system = "x86_64-linux"; in {
|
||||
# ↓ this is the home-manager output in the flake schema
|
||||
homeConfigurations."yourUsername»" = home-manager.lib.homeManagerConfiguration {
|
||||
pkgs = nixpkgs.legacyPackages.x86_64-linux;
|
||||
# ↓ this is your home output in the flake schema, expected by home-manager
|
||||
"your-username@your-hostname" = home-manager.lib.homeManagerConfiguration
|
||||
modules = [
|
||||
neovim-flake.homeManagerModules.default # <- this imports the home-manager module that provides the options
|
||||
./home.nix # your home-manager configuration, probably where you will want to add programs.neovim-flake options
|
||||
nvf.homeManagerModules.default # <- this imports the home-manager module that provides the options
|
||||
./home.nix # <- your home entrypoint
|
||||
];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Once the module is imported, we will be able to define the following options (and much more) from inside the
|
||||
home-manager configuration.
|
||||
Once the module is properly imported by your host, you will be able to use the
|
||||
`programs.nvf` module option anywhere in your configuration in order to
|
||||
configure **nvf**.
|
||||
|
||||
```nix{
|
||||
programs.neovim-flake = {
|
||||
programs.nvf = {
|
||||
enable = true;
|
||||
# your settings need to go into the settings attribute set
|
||||
# most settings are documented in the appendix
|
||||
|
|
@ -74,6 +76,8 @@ home-manager configuration.
|
|||
}
|
||||
```
|
||||
|
||||
:::{.note}
|
||||
You may find all avaliable options in the [appendix](https://notashelf.github.io/neovim-flake/options)
|
||||
::: {.note}
|
||||
**nvf** exposes a lot of options, most of which are not referenced in the
|
||||
installation sections of the manual. You may find all avaliable options
|
||||
in the [appendix](https://notashelf.github.io/nvf/options)
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -1,3 +1,82 @@
|
|||
# NixOS Module {#ch-nixos-module}
|
||||
|
||||
This artice is a stub. It will be written as the NixOS module is finalized.
|
||||
The NixOS module allows us to customize the different `vim` options from inside
|
||||
the NixOS configuration without having to call for the wrapper yourself. It is
|
||||
the recommended way to use **nvf** alongside the home-manager module depending
|
||||
on your needs.
|
||||
|
||||
To use it, we first add the input flake.
|
||||
|
||||
```nix
|
||||
{
|
||||
inputs = {
|
||||
obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
|
||||
nvf = {
|
||||
url = "github:notashelf/nvf";
|
||||
# you can override input nixpkgs
|
||||
inputs.nixpkgs.follows = "nixpkgs";
|
||||
# you can also override individual plugins
|
||||
# for example:
|
||||
inputs.obsidian-nvim.follows = "obsidian-nvim"; # <- this will use the obsidian-nvim from your inputs
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Followed by importing the NixOS module somewhere in your configuration.
|
||||
|
||||
```nix
|
||||
{
|
||||
# assuming nvf is in your inputs and inputs is in the argset
|
||||
# see example below
|
||||
imports = [ inputs.nvf.nixosModules.default ];
|
||||
}
|
||||
```
|
||||
|
||||
## Example Installation {#sec-example-installation}
|
||||
|
||||
```nix
|
||||
{
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
nvf.url = "github:notashelf/nvf";
|
||||
};
|
||||
|
||||
outputs = { nixpkgs, nvf, ... }: let
|
||||
system = "x86_64-linux"; in {
|
||||
# ↓ this is your host output in the flake schema
|
||||
nixosConfigurations."yourUsername»" = nixpkgs.lib.nixosSystem {
|
||||
modules = [
|
||||
nvf.nixosModules.default # <- this imports the NixOS module that provides the options
|
||||
./configuration.nix # <- your host entrypoint
|
||||
];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Once the module is properly imported by your host, you will be able to use the
|
||||
`programs.nvf` module option anywhere in your configuration in order to
|
||||
configure **nvf**.
|
||||
|
||||
```nix{
|
||||
programs.nvf = {
|
||||
enable = true;
|
||||
# your settings need to go into the settings attribute set
|
||||
# most settings are documented in the appendix
|
||||
settings = {
|
||||
vim.viAlias = false;
|
||||
vim.vimAlias = true;
|
||||
vim.lsp = {
|
||||
enable = true;
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
**nvf** exposes a lot of options, most of which are not referenced in the
|
||||
installation sections of the manual. You may find all avaliable options
|
||||
in the [appendix](https://notashelf.github.io/nvf/options)
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -1,35 +1,54 @@
|
|||
# Standalone Installation (home-manager) {#ch-standalone-home-manager}
|
||||
# Standalone Installation on Home-Manager {#ch-standalone-hm}
|
||||
|
||||
The following is an example of a barebones vim configuration with the default theme enabled.
|
||||
Your built Neoevim configuration can be exposed as a flake output to make it
|
||||
easier to share across machines, repositories and so on. Or it can be added to
|
||||
your system packages to make it available across your system.
|
||||
|
||||
The following is an example installation of `nvf` as a standalone package with
|
||||
the default theme enabled. You may use other options inside `config.vim` in
|
||||
`configModule`, but this example will not cover that.
|
||||
|
||||
```nix
|
||||
{
|
||||
inputs.neovim-flake = {
|
||||
url = "github:notashelf/neovim-flake";
|
||||
inputs.nixpkgs.follows = "nixpkgs";
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
home-manager.url = "github:nix-community/home-manager";
|
||||
nvf.url = "github:notashelf/nvf";
|
||||
};
|
||||
|
||||
outputs = {nixpkgs, neovim-flake, ...}: let
|
||||
outputs = {nixpkgs, home-manager, nvf, ...}: let
|
||||
system = "x86_64-linux";
|
||||
pkgs = nixpkgs.legacyPackages.${system};
|
||||
configModule = {
|
||||
# Add any custom options (and feel free to upstream them!)
|
||||
# options = ...
|
||||
# Add any custom options (and do feel free to upstream them!)
|
||||
# options = { ... };
|
||||
|
||||
config.vim = {
|
||||
theme.enable = true;
|
||||
# and more options as you see fit...
|
||||
};
|
||||
};
|
||||
|
||||
customNeovim = neovim-flake.lib.neovimConfiguration {
|
||||
customNeovim = nvf.lib.neovimConfiguration {
|
||||
modules = [configModule];
|
||||
inherit pkgs;
|
||||
};
|
||||
in {
|
||||
# this is an example nixosConfiguration using the built neovim package
|
||||
# this will make the package available as a flake input
|
||||
packages.${system}.my-neovim = customNeovim.neovim;
|
||||
|
||||
# this is an example home-manager configuration
|
||||
# using the built neovim package
|
||||
homeConfigurations = {
|
||||
yourHostName = home-manager.lib.nixosSystem {
|
||||
# TODO
|
||||
"your-username@your-hostname" = home-manager.lib.homeManagerConfiguration {
|
||||
# ...
|
||||
modules = [
|
||||
./home.nix
|
||||
|
||||
# this will make wrapped neovim available in your system packages
|
||||
{environment.systemPackages = [customNeovim.neovim];}
|
||||
];
|
||||
# ...
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,33 +1,41 @@
|
|||
# Standalone Installation (NixOS) {#ch-standalone-nixos}
|
||||
# Standalone Installation on NixOS {#ch-standalone-nixos}
|
||||
|
||||
The following is an example of a barebones vim configuration with the default theme enabled.
|
||||
Your built Neoevim configuration can be exposed as a flake output to make it
|
||||
easier to share across machines, repositories and so on. Or it can be added to
|
||||
your system packages to make it available across your system.
|
||||
|
||||
The following is an example installation of `nvf` as a standalone package with
|
||||
the default theme enabled. You may use other options inside `config.vim` in
|
||||
`configModule`, but this example will not cover that.
|
||||
|
||||
```nix
|
||||
{
|
||||
inputs.neovim-flake = {
|
||||
url = "github:notashelf/neovim-flake";
|
||||
inputs.nixpkgs.follows = "nixpkgs";
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
home-manager.url = "github:nix-community/home-manager";
|
||||
nvf.url = "github:notashelf/nvf";
|
||||
};
|
||||
|
||||
outputs = {nixpkgs, neovim-flake, ...}: let
|
||||
outputs = {nixpkgs, nvf, ...}: let
|
||||
system = "x86_64-linux";
|
||||
pkgs = nixpkgs.legacyPackages.${system};
|
||||
configModule = {
|
||||
# Add any custom options (and feel free to upstream them!)
|
||||
# options = ...
|
||||
# Add any custom options (and do feel free to upstream them!)
|
||||
# options = { ... };
|
||||
|
||||
config.vim = {
|
||||
theme.enable = true;
|
||||
# and more options as you see fit...
|
||||
};
|
||||
};
|
||||
|
||||
customNeovim = neovim-flake.lib.neovimConfiguration {
|
||||
customNeovim = nvf.lib.neovimConfiguration {
|
||||
modules = [configModule];
|
||||
inherit pkgs;
|
||||
};
|
||||
in {
|
||||
# this will make the package available as a flake input
|
||||
packages.${system}.neovim = customNeovim.neovim;
|
||||
packages.${system}.my-neovim = customNeovim.neovim;
|
||||
|
||||
# this is an example nixosConfiguration using the built neovim package
|
||||
nixosConfigurations = {
|
||||
|
|
@ -45,7 +53,3 @@ The following is an example of a barebones vim configuration with the default th
|
|||
};
|
||||
}
|
||||
```
|
||||
|
||||
Your built neovim configuration can be exposed as a flake output, or be added to your system packages to make
|
||||
it available across your system. You may also consider passing the flake output to home-manager to make it available
|
||||
to a specific user.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# neovim-flake-manual {#neovim-flake-manual}
|
||||
# nvf manual {#nvf-manual}
|
||||
|
||||
## Version @NVF_VERSION@
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Neovim Flake Configuration Options {#ch-options}
|
||||
|
||||
Below are the options provided by neovim-flake provided in no particular order.
|
||||
Below are the options provided by nvf provided in no particular order.
|
||||
They may include useful comments and warnings, or examples on how a module option
|
||||
is meant to be used.
|
||||
|
||||
```{=include=} options
|
||||
id-prefix: opt-
|
||||
list-id: neovim-flake-options
|
||||
list-id: nvf-options
|
||||
source: @OPTIONS_JSON@
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Preface {#ch-preface}
|
||||
|
||||
If you noticed a bug caused by neovim-flake then please consider reporting it over
|
||||
[the neovim-flake issue tracker](https://github.com/notashelf/neovim-flake/issues).
|
||||
If you noticed a bug caused by **nvf** then please consider reporting it over
|
||||
[the issue tracker](https://github.com/notashelf/nvf/issues).
|
||||
|
||||
Bugfixes, feature additions and upstreamed changes from your local configurations
|
||||
are always welcome in the [the neovim-flake pull requests tab](https://github.com/notashelf/neovim-flake/pulls).
|
||||
are always welcome in the [the pull requests tab](https://github.com/notashelf/nvf/pulls).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Try it out {#ch-try-it-out}
|
||||
|
||||
Thanks to the portability of Nix, you can try out neovim-flake without actually installing it to your machine.
|
||||
Thanks to the portability of Nix, you can try out nvf without actually installing it to your machine.
|
||||
Below are the commands you may run to try out different configurations provided by this flake. As of v0.5, three
|
||||
configurations are provided:
|
||||
|
||||
|
|
@ -11,8 +11,8 @@ configurations are provided:
|
|||
You may try out any of the provided configurations using the `nix run` command on a system where Nix is installed.
|
||||
|
||||
```console
|
||||
$ cachix use neovim-flake # Optional: it'll save you CPU resources and time
|
||||
$ nix run github:notashelf/neovim-flake#nix # will run the default minimal configuration
|
||||
$ cachix use nvf # Optional: it'll save you CPU resources and time
|
||||
$ nix run github:notashelf/nvf#nix # will run the default minimal configuration
|
||||
```
|
||||
|
||||
Do keep in mind that this is **susceptible to garbage collection** meaning it will be removed from your Nix store
|
||||
|
|
@ -21,9 +21,9 @@ once you garbage collect.
|
|||
## Using Prebuilt Configs {#sec-using-prebuild-configs}
|
||||
|
||||
```console
|
||||
$ nix run github:notashelf/neovim-flake#nix
|
||||
$ nix run github:notashelf/neovim-flake#tidal
|
||||
$ nix run github:notashelf/neovim-flake#maximal
|
||||
$ nix run github:notashelf/nvf#nix
|
||||
$ nix run github:notashelf/nvf#tidal
|
||||
$ nix run github:notashelf/nvf#maximal
|
||||
```
|
||||
|
||||
### Available Configs {#sec-available-configs}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
# Release Notes {#ch-release-notes}
|
||||
|
||||
This section lists the release notes for tagged version of neovim-flake and current main.
|
||||
This section lists the release notes for tagged version of **nvf** and
|
||||
the current main current main branch
|
||||
|
||||
```{=include=} chapters
|
||||
rl-0.1.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue