<divclass="preface"><divclass="titlepage"><div><div><h1id="ch-preface"class="title">Preface </h1></div></div></div><p>If you noticed a bug caused by <spanclass="strong"><strong>nvf</strong></span> then please consider reporting it over
<aclass="link"href="https://github.com/notashelf/nvf/issues"target="_top">the issue tracker</a>.</p><p>Bugfixes, feature additions and upstreamed changes from your local configurations
are always welcome in the <aclass="link"href="https://github.com/notashelf/nvf/pulls"target="_top">the pull requests tab</a>.</p>
</div><divclass="preface"><divclass="titlepage"><div><div><h1id="ch-try-it-out"class="title">Try it out </h1></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-using-prebuild-configs">Using Prebuilt Configs</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-available-configs">Available Configs</a></span></dt></dl></dd></dl></div><p>Thanks to the portability of Nix, you can try out nvf without actually installing it to your machine.
configurations are provided:</p><divclass="itemizedlist"><ulclass="itemizedlist compact"style="list-style-type: disc;"><liclass="listitem"><p>Nix</p></li><liclass="listitem"><p>Maximal</p></li></ul></div><p>You may try out any of the provided configurations using the <codeclass="literal">nix run</code> command on a system where Nix is installed.</p><pre><codeclass="programlisting console">$ cachix use nvf # Optional: it'll save you CPU resources and time
</code></pre><p>Do keep in mind that this is <spanclass="strong"><strong>susceptible to garbage collection</strong></span> meaning it will be removed from your Nix store
once you garbage collect.</p><divclass="section"><divclass="titlepage"><div><div><h2id="sec-using-prebuild-configs"class="title">Using Prebuilt Configs </h2></div></div></div><divclass="toc"><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-available-configs">Available Configs</a></span></dt></dl></div><pre><codeclass="programlisting console">$ nix run github:notashelf/nvf#nix
$ nix run github:notashelf/nvf#maximal
</code></pre><divclass="section"><divclass="titlepage"><div><div><h3id="sec-available-configs"class="title">Available Configs </h3></div></div></div><divclass="section"><divclass="titlepage"><div><div><h4id="sec-configs-nix"class="title">Nix </h4></div></div></div><p><codeclass="literal">Nix</code> configuration by default provides LSP/diagnostic support for Nix alongisde a set of visual and functional plugins.
By running <codeclass="literal">nix run .#</code>, which is the default package, you will build Neovim with this config.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h4id="sec-configs-maximal"class="title">Maximal </h4></div></div></div><p><codeclass="literal">Maximal</code> is the ultimate configuration that will enable support for more commonly used language as well as additional
complementary plugins. Keep in mind, however, that this will pull a lot of dependencies.</p><p>You are <spanclass="emphasis"><em>strongly</em></span> recommended to use the binary cache if you would like to try the Maximal configuration.</p>
</div><divclass="part"><divclass="titlepage"><div><div><h1id="ch-default-configs"class="title">Default Configs </h1></div></div></div><divclass="partintro"><p>While you can configure <spanclass="strong"><strong>nvf</strong></span> yourself using the builder, you can also use the pre-built configs that are available.
Here are a few default configurations you can use.</p><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="chapter"><ahref="index.xhtml#sec-default-maximal">Maximal</a></span></dt><dt><spanclass="chapter"><ahref="index.xhtml#sec-default-nix">Nix</a></span></dt></dl></div></div><divclass="chapter"><divclass="titlepage"><div><div><h2id="sec-default-maximal"class="title">Maximal </h2></div></div></div><pre><codeclass="programlisting bash">$ nix shell github:notashelf/nvf#maximal test.nix
</code></pre><p>It is the same fully configured Neovim as with the <aclass="link"href="index.xhtml#sec-default-nix"title="Nix">Nix</a>
configuration, but with every supported language enabled.</p><divclass="note"><h3class="title">Note</h3><p>Running the maximal config will download <spanclass="emphasis"><em>a lot</em></span> of packages as it is
downloading language servers, formatters, and more.</p></div>
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="sec-default-nix"class="title">Nix </h2></div></div></div><pre><codeclass="programlisting bash">$ nix run github:notashelf/nvf#nix test.nix
</code></pre><p>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.</p>
</div>
</div><divclass="part"><divclass="titlepage"><div><div><h1id="ch-installation"class="title">Installing nvf </h1></div></div></div><divclass="partintro"><p>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 <aclass="link"href="index.xhtml#ch-module-installation"title="Module Installation">module installation section</a></p><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="chapter"><ahref="index.xhtml#ch-standalone-installation">Standalone Installation</a></span></dt><dd><dl><dt><spanclass="chapter"><ahref="index.xhtml#ch-standalone-nixos">Standalone Installation on NixOS</a></span></dt><dt><spanclass="chapter"><ahref="index.xhtml#ch-standalone-hm">Standalone Installation on Home-Manager</a></span></dt></dl></dd><dt><spanclass="chapter"><ahref="index.xhtml#ch-module-installation">Module Installation</a></span></dt><dd><dl><dt><spanclass="chapter"><ahref="index.xhtml#ch-nixos-module">NixOS Module</a></span></dt><dt><spanclass="chapter"><ahref="index.xhtml#ch-hm-module">Home-Manager Module</a></span></dt></dl></dd></dl></div></div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-standalone-installation"class="title">Standalone Installation </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="chapter"><ahref="index.xhtml#ch-standalone-nixos">Standalone Installation on NixOS</a></span></dt><dt><spanclass="chapter"><ahref="index.xhtml#ch-standalone-hm">Standalone Installation on Home-Manager</a></span></dt></dl></div><p>It is possible to install <spanclass="strong"><strong>nvf</strong></span> without depending on NixOS or home-manager as the parent
module system, using the <codeclass="literal">neovimConfiguration</code> function exposed by <spanclass="strong"><strong>nvf</strong></span> extended library.
It takes in the configuration as a module, and returns an attribute set as a result.</p><pre><codeclass="programlisting nix">{
</code></pre><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-standalone-nixos"class="title">Standalone Installation on NixOS </h2></div></div></div><p>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.</p><p>The following is an example installation of <codeclass="literal">nvf</code> as a standalone package with
the default theme enabled. You may use other options inside <codeclass="literal">config.vim</code> in
<codeclass="literal">configModule</code>, but this example will not cover that.</p><pre><codeclass="programlisting nix">{
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-standalone-hm"class="title">Standalone Installation on Home-Manager </h2></div></div></div><p>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.</p><p>The following is an example installation of <codeclass="literal">nvf</code> as a standalone package with
the default theme enabled. You may use other options inside <codeclass="literal">config.vim</code> in
<codeclass="literal">configModule</code>, but this example will not cover that.</p><pre><codeclass="programlisting nix">{
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-module-installation"class="title">Module Installation </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="chapter"><ahref="index.xhtml#ch-nixos-module">NixOS Module</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-example-installation-nixos">Example Installation</a></span></dt></dl></dd><dt><spanclass="chapter"><ahref="index.xhtml#ch-hm-module">Home-Manager Module</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-example-installation-hm">Example Installation</a></span></dt></dl></dd></dl></div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-nixos-module"class="title">NixOS Module </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-example-installation-nixos">Example Installation</a></span></dt></dl></div><p>The NixOS module allows us to customize the different <codeclass="literal">vim</code> options from inside
the NixOS configuration without having to call for the wrapper yourself. It is
the recommended way to use <spanclass="strong"><strong>nvf</strong></span> alongside the home-manager module depending
on your needs.</p><p>To use it, we first add the input flake.</p><pre><codeclass="programlisting nix">{
# 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;
};
};
};
}
</code></pre><divclass="note"><h3class="title">Note</h3><p><spanclass="strong"><strong>nvf</strong></span> 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 <aclass="link"href="https://notashelf.github.io/nvf/options"target="_top">appendix</a></p></div>
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-hm-module"class="title">Home-Manager Module </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-example-installation-hm">Example Installation</a></span></dt></dl></div><p>The home-manager module allows us to customize the different <codeclass="literal">vim</code> options from
inside the home-manager configuration without having to call for the wrapper
yourself. It is the recommended way to use <spanclass="strong"><strong>nvf</strong></span> alongside the NixOS module
depending on your needs.</p><p>To use it, we first add the input flake.</p><pre><codeclass="programlisting nix">{
</code></pre><divclass="note"><h3class="title">Note</h3><p><spanclass="strong"><strong>nvf</strong></span> 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 <aclass="link"href="https://notashelf.github.io/nvf/options"target="_top">appendix</a></p></div>
</div>
</div>
</div>
</div><divclass="part"><divclass="titlepage"><div><div><h1id="ch-configuring"class="title">Configuring nvf </h1></div></div></div><divclass="partintro"><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="chapter"><ahref="index.xhtml#ch-custom-package">Custom Neovim Package</a></span></dt><dt><spanclass="chapter"><ahref="index.xhtml#ch-custom-plugins">Custom Plugins</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#ch-adding-plugins">Adding Plugins</a></span></dt></dl></dd><dt><spanclass="chapter"><ahref="index.xhtml#ch-languages">Language Support</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-languages-custom-lsp-packages">LSP Custom Packages/Command</a></span></dt></dl></dd><dt><spanclass="chapter"><ahref="index.xhtml#ch-using-dags">Using DAGs</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entryAnywhere">entryAnywhere</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#ch-types-dag-entryAfter">entryAfter</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#ch-types-dag-entryBefore">entryBefore</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entryBetween">entryBetween</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesAnywhere">entriesAnywhere</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesAfter">entriesAfter</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesBefore">entriesBefore</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesBetween">entriesBetween</a></span></dt></dl></dd></dl></div></div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-custom-package"class="title">Custom Neovim Package </h2></div></div></div><p>As of v0.5, you may now specify the Neovim package that will be wrapped with
your configuration. This is done with the <codeclass="literal">vim.package</code> option.</p><pre><codeclass="programlisting nix">{inputs, pkgs, ...}: {
</code></pre><p>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 <codeclass="literal">neovim-unwrapped</code> in nixpkgs.</p><pre><codeclass="programlisting nix">{ pkgs, ...}: {
# using the neovim-nightly overlay
vim.package = pkgs.neovim-unwrapped;
}
</code></pre>
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-custom-plugins"class="title">Custom Plugins </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#ch-adding-plugins">Adding Plugins</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-configuring-plugins">Configuring</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-new-method">New Method</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-old-method">Old Method</a></span></dt></dl></dd></dl></div><p><spanclass="strong"><strong>nvf</strong></span>, by default, exposes a wide variety of plugins as module options
for your convience and bundles necessary dependencies into <spanclass="strong"><strong>nvf</strong></span>’s runtime.
In case a plugin is not available in <spanclass="strong"><strong>nvf</strong></span>, you may consider making a pull
request to <spanclass="strong"><strong>nvf</strong></span> to include it as a module or you may add it to your
configuration locally.</p><divclass="section"><divclass="titlepage"><div><div><h2id="ch-adding-plugins"class="title"style="clear: both">Adding Plugins </h2></div></div></div><divclass="toc"><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-configuring-plugins">Configuring</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-new-method">New Method</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-old-method">Old Method</a></span></dt></dl></div><p>There are multiple ways of adding custom plugins to your <spanclass="strong"><strong>nvf</strong></span> configuration.</p><p>You can use custom plugins, before they are implemented in the flake. To add a
plugin to the runtime, you need to add it to the <codeclass="literal">vim.startPlugins</code> list in
your configuration.</p><p>Adding a plugin to <codeclass="literal">startPlugins</code> will not allow you to configure the plugin
that you have adeed, but <spanclass="strong"><strong>nvf</strong></span> provides multiple way of configuring any
custom plugins that you might have added to your configuration.</p><divclass="section"><divclass="titlepage"><div><div><h3id="sec-configuring-plugins"class="title">Configuring </h3></div></div></div><p>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 <codeclass="literal">config.vim.configRC</code> or <codeclass="literal">config.vim.luaConfigRC</code> respectively. Both of
these options are attribute sets, and you need to give the configuration you’re
adding some name, like this:</p><pre><codeclass="programlisting nix">{
# this will create an "aquarium" section in your init.vim with the contents of your custom config
# which will be *appended* to the rest of your configuration, inside your init.vim
to find out more about the DAG system.</p></div><p>If you successfully made your plugin work, please feel free to create a PR to
add it to <spanclass="strong"><strong>nvf</strong></span> or open an issue with your findings so that we can make it
available for everyone easily.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h3id="sec-new-method"class="title">New Method </h3></div></div></div><p>As of version <spanclass="strong"><strong>0.5</strong></span>, we have a more extensive API for configuring plugins,
under <codeclass="literal">vim.extraPlugins</code>. Instead of using DAGs exposed by the library, you may
use the extra plugin module as follows:</p><pre><codeclass="programlisting nix">{
</div><divclass="section"><divclass="titlepage"><div><div><h3id="sec-old-method"class="title">Old Method </h3></div></div></div><p>Prior to version 0.5, the method of adding new plugins was adding the plugin
package to <codeclass="literal">vim.startPlugins</code> and add its configuration as a DAG under one of
<codeclass="literal">vim.configRC</code> or <codeclass="literal">vim.luaConfigRC</code>. 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.</p><divclass="section"><divclass="titlepage"><div><div><h4id="sec-adding-plugins"class="title">Adding plugins </h4></div></div></div><p>To add a plugin to <spanclass="strong"><strong>nvf</strong></span>’s runtime, you may add it</p><pre><codeclass="programlisting nix">{pkgs, ...}: {
# add a package from nixpkgs to startPlugins
vim.startPlugins = [
pkgs.vimPlugins.aerial-nvim ];
}
</code></pre><p>And to configure the added plugin, you can use the <codeclass="literal">luaConfigRC</code> option to
provide configuration as a DAG using the <spanclass="strong"><strong>nvf</strong></span> extended library.</p><pre><codeclass="programlisting nix">{inputs, ...}: let
# assuming you have an input called nvf pointing at the nvf repository
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-languages"class="title">Language Support </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-languages-custom-lsp-packages">LSP Custom Packages/Command</a></span></dt></dl></div><p>Language specific support means there is a combination of language specific
plugins, <codeclass="literal">treesitter</code> support, <codeclass="literal">nvim-lspconfig</code> language servers, and <codeclass="literal">null-ls</code>
integration. This gets you capabilities ranging from autocompletion to formatting
to diagnostics. The following languages have sections under the <codeclass="literal">vim.languages</code>
attribute.</p><divclass="itemizedlist"><ulclass="itemizedlist compact"style="list-style-type: disc;"><liclass="listitem"><p>Rust: <aclass="link"href="options.html#opt-vim.languages.rust.enable">vim.languages.rust.enable</a></p></li><liclass="listitem"><p>Nix: <aclass="link"href="options.html#opt-vim.languages.nix.enable">vim.languages.nix.enable</a></p></li><liclass="listitem"><p>SQL: <aclass="link"href="options.html#opt-vim.languages.sql.enable">vim.languages.sql.enable</a></p></li><liclass="listitem"><p>C/C++: <aclass="link"href="options.html#opt-vim.languages.clang.enable">vim.languages.clang.enable</a></p></li><liclass="listitem"><p>Typescript/Javascript: <aclass="link"href="options.html#opt-vim.languages.ts.enable">vim.languages.ts.enable</a></p></li><liclass="listitem"><p>Python: <aclass="link"href="options.html#opt-vim.languages.python.enable">vim.languages.python.enable</a>:</p></li><liclass="listitem"><p>Zig: <aclass="link"href="options.html#opt-vim.languages.zig.enable">vim.languages.zig.enable</a></p></li><liclass="listitem"><p>Markdown: <aclass="link"href="options.html#opt-vim.languages.markdown.enable">vim.languages.markdown.enable</a></p></li><liclass="listitem"><p>HTML: <aclass="link"href="options.html#opt-vim.languages.html.enable">vim.languages.html.enable</a></p></li><liclass="listitem"><p>Dart: <aclass="link"href="options.html#opt-vim.languages.dart.enable">vim.languages.dart.enable</a></p></li><liclass="listitem"><p>Go: <aclass="link"href="options.html#opt-vim.languages.go.enable">vim.languages.go.enable</a></p></li><liclass="listitem"><p>Lua: <aclass="link"href="options.html#opt-vim.languages.lua.enable">vim.languages.lua.enable</a></p></li><liclass="listitem"><p>PHP: <aclass="link"href="options.html#opt-vim.languages.php.enable">vim.languages.php.enable</a></p></li></ul></div><p>Adding support for more languages, and improving support for existing ones are great places
where you can contribute with a PR.</p><divclass="section"><divclass="titlepage"><div><div><h2id="sec-languages-custom-lsp-packages"class="title"style="clear: both">LSP Custom Packages/Command </h2></div></div></div><p>In any of the <codeclass="literal">opt.languages.<language>.lsp.package</code> 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 <codeclass="literal">$PATH</code> during runtime, for
</div><divclass="chapter"><divclass="titlepage"><div><div><h2id="ch-using-dags"class="title">Using DAGs </h2></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entryAnywhere">entryAnywhere</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#ch-types-dag-entryAfter">entryAfter</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#ch-types-dag-entryBefore">entryBefore</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entryBetween">entryBetween</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesAnywhere">entriesAnywhere</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesAfter">entriesAfter</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesBefore">entriesBefore</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-types-dag-entriesBetween">entriesBetween</a></span></dt></dl></div><p>We conform to the NixOS options types for the most part, however, a noteworthy
addition for certain options is the <aclass="link"href="https://en.wikipedia.org/wiki/Directed_acyclic_graph"target="_top"><spanclass="strong"><strong>DAG
(Directed acyclic graph)</strong></span></a>
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
<codeclass="literal">configRC</code> or <codeclass="literal">luaConfigRC</code>.</p><p>The below section, mostly taken from the <aclass="link"href="https://raw.githubusercontent.com/nix-community/home-manager/master/docs/manual/writing-modules/types.md"target="_top">home-manager
manual</a>
explains in more detail the overall usage logic of the DAG type.</p><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entryAnywhere"class="title"style="clear: both">entryAnywhere </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entryAnywhere (value: T) : DagEntry<T></code></p></blockquote></div><p>Indicates that <codeclass="literal">value</code> can be placed anywhere within the DAG.
This is also the default for plain attribute set entries, that
</div><divclass="section"><divclass="titlepage"><div><div><h2id="ch-types-dag-entryAfter"class="title"style="clear: both">entryAfter </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entryAfter (afters: list string) (value: T) : DagEntry<T></code></p></blockquote></div><p>Indicates that <codeclass="literal">value</code> must be placed <spanclass="emphasis"><em>after</em></span> each of the
attribute names in the given list. For example</p><pre><codeclass="programlisting nix">foo.bar = {
a = 0;
b = lib.dag.entryAfter [ "a" ] 1;
}
</code></pre><p>would place <codeclass="literal">b</code> after <codeclass="literal">a</code> in the graph.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="ch-types-dag-entryBefore"class="title"style="clear: both">entryBefore </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entryBefore (befores: list string) (value: T) : DagEntry<T></code></p></blockquote></div><p>Indicates that <codeclass="literal">value</code> must be placed <spanclass="emphasis"><em>before</em></span> each of the
attribute names in the given list. For example</p><pre><codeclass="programlisting nix">foo.bar = {
b = lib.dag.entryBefore [ "a" ] 1;
a = 0;
}
</code></pre><p>would place <codeclass="literal">b</code> before <codeclass="literal">a</code> in the graph.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entryBetween"class="title"style="clear: both">entryBetween </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T></code></p></blockquote></div><p>Indicates that <codeclass="literal">value</code> must be placed <spanclass="emphasis"><em>before</em></span> the attribute
names in the first list and <spanclass="emphasis"><em>after</em></span> the attribute names in the
second list. For example</p><pre><codeclass="programlisting nix">foo.bar = {
a = 0;
c = lib.dag.entryBetween [ "b" ] [ "a" ] 2;
b = 1;
}
</code></pre><p>would place <codeclass="literal">c</code> before <codeclass="literal">b</code> and after <codeclass="literal">a</code> in the graph.</p><p>There are also a set of functions that generate a DAG from a list.
These are convenient when you just want to have a linear list of DAG
entries, without having to manually enter the relationship between
each entry. Each of these functions take a <codeclass="literal">tag</code> as argument and the
DAG entries will be named <codeclass="literal">${tag}-${index}</code>.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entriesAnywhere"class="title"style="clear: both">entriesAnywhere </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entriesAnywhere (tag: string) (values: [T]) : Dag<T></code></p></blockquote></div><p>Creates a DAG with the given values with each entry labeled
using the given tag. For example</p><pre><codeclass="programlisting nix">foo.bar = lib.dag.entriesAnywhere "a" [ 0 1 ];
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entriesAfter"class="title"style="clear: both">entriesAfter </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T></code></p></blockquote></div><p>Creates a DAG with the given values with each entry labeled
using the given tag. The list of values are placed are placed
<spanclass="emphasis"><em>after</em></span> each of the attribute names in <codeclass="literal">afters</code>. For example</p><pre><codeclass="programlisting nix">foo.bar =
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entriesBefore"class="title"style="clear: both">entriesBefore </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T></code></p></blockquote></div><p>Creates a DAG with the given values with each entry labeled
using the given tag. The list of values are placed <spanclass="emphasis"><em>before</em></span> each
of the attribute names in <codeclass="literal">befores</code>. For example</p><pre><codeclass="programlisting nix"> foo.bar =
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-types-dag-entriesBetween"class="title"style="clear: both">entriesBetween </h2></div></div></div><divclass="blockquote"><blockquoteclass="blockquote"><p><codeclass="literal">lib.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T></code></p></blockquote></div><p>Creates a DAG with the given values with each entry labeled
using the given tag. The list of values are placed <spanclass="emphasis"><em>before</em></span> each
of the attribute names in <codeclass="literal">befores</code> and <spanclass="emphasis"><em>after</em></span> each of the
attribute names in <codeclass="literal">afters</code>. For example</p><pre><codeclass="programlisting nix">foo.bar =
</div><divclass="chapter"><divclass="titlepage"><div><div><h1id="ch-hacking"class="title">Hacking nvf </h1></div></div></div><divclass="toc"><p><strong>Table of Contents</strong></p><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-contrib-getting-started">Getting Started</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines">Guidelines</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-documentation">Adding Documentation</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-formatting">Formatting Code</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-commit-message-style">Formatting Commits</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-commit-style">Commit Style</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-ex-commit-message">Example Commit</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-code-style">Code Style</a></span></dt></dl></dd><dt><spanclass="section"><ahref="index.xhtml#sec-testing-changes">Testing Changes</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-keybinds">Keybinds</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-custom-key-mappings">Custom Key Mappings Support for a Plugin</a></span></dt></dl></dd><dt><spanclass="section"><ahref="index.xhtml#sec-additional-plugins">Adding Plugins</a></span></dt><dd><dl><dt><spanclass="section"><ahref="index.xhtml#sec-modular-setup-options">Modular setup options</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-details-of-toluaobject">Details of toLuaObject</a></span></dt></dl></dd></dl></div><p><spanclass="strong"><strong>nvf</strong></span> is designed for developers as much as it is for the end user. I would like any potential contributor
into <spanclass="strong"><strong>nvf</strong></span>’s development without leaving question marks in your head.</p><p>This section is mainly directed towards those who wish to contribute code into <spanclass="strong"><strong>nvf</strong></span>. If you wish to instead
occurs or a feature should be implemented.</p><divclass="section"><divclass="titlepage"><div><div><h1id="sec-contrib-getting-started"class="title"style="clear: both">Getting Started </h1></div></div></div><p>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 <aclass="link"href="https://help.github.com/articles/fork-a-repo/"target="_top">Fork a repo guide</a>
for instructions on how you can do this. Once you have a fork of <spanclass="strong"><strong>nvf</strong></span>, you
should create a separate branch based on the msot recent <codeclass="literal">main</code> branch. Give
your branch a reasonably descriptive name (e.g. <codeclass="literal">feature/debugger</code> or
<codeclass="literal">fix/pesky-bug</code>) and you are ready to work on your changes</p><p>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 <aclass="link"href="index.xhtml#sec-guidelines"title="Guidelines">Contributing
Guidelines</a>, push the branch to GitHub and <aclass="link"href="https://help.github.com/articles/creating-a-pull-request"target="_top">create a pull
request</a>. The default
pull request template available on the <spanclass="strong"><strong>nvf</strong></span> 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.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h1id="sec-guidelines"class="title"style="clear: both">Guidelines </h1></div></div></div><divclass="toc"><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-documentation">Adding Documentation</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-formatting">Formatting Code</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-commit-message-style">Formatting Commits</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-commit-style">Commit Style</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-ex-commit-message">Example Commit</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-guidelines-code-style">Code Style</a></span></dt></dl></div><p>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.</p><p>If you are uncertain how these rules affect the change you would like to make
then feel free to start a discussion in the <aclass="link"href="https://github.com/NotAShelf/nvf/discussions"target="_top">discussions tab</a>
ideally (but not necessarily) before you start developing.</p><divclass="section"><divclass="titlepage"><div><div><h2id="sec-guidelines-documentation"class="title"style="clear: both">Adding Documentation </h2></div></div></div><p>Most, if not all, changes warrant changes to the documentation. Module options
should be documented with <aclass="link"href="https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup"target="_top">Nixpkgs-flavoured Markdown</a>,
albeit with exceptions.</p><divclass="note"><h3class="title">Note</h3><p>As of <spanclass="strong"><strong>v0.5</strong></span>, <spanclass="strong"><strong>nvf</strong></span> is itself documented using full markdown in both module
options and the manual. With <spanclass="strong"><strong>v0.6</strong></span>, this manual has also been converted to
markdown in full.</p></div><p>The HTML version of this manual containing both the module option descriptions
and the documentation of <spanclass="strong"><strong>nvf</strong></span> (such as this page) can be generated and
opened by typing the following in a shell within a clone of the <spanclass="strong"><strong>nvf</strong></span> Git
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-guidelines-formatting"class="title"style="clear: both">Formatting Code </h2></div></div></div><p>Make sure your code is formatted as described in <aclass="link"href="index.xhtml#sec-guidelines-code-style"title="Code Style">code-style
section</a>. To maintain consistency throughout the
project you are encouraged to browse through existing code and adopt its style
also in new code.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-guidelines-commit-message-style"class="title"style="clear: both">Formatting Commits </h2></div></div></div><p>Similar to <aclass="link"href="index.xhtml#sec-guidelines-code-style"title="Code Style">code style guidelines</a> we encourage a
consistent commit message format as described in <aclass="link"href="index.xhtml#sec-guidelines-commit-style"title="Commit Style">commit style
guidelines</a>.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-guidelines-commit-style"class="title"style="clear: both">Commit Style </h2></div></div></div><p>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.</p><p>The commit messages should follow the <aclass="link"href="https://chris.beams.io/posts/git-commit/#seven-rule"target="_top">seven
rules</a>, 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</p><pre><codeclass="programlisting"> {component}: {description}
</code></pre><p>where <codeclass="literal">{component}</code> refers to the code component (or module) your change
affects, <codeclass="literal">{description}</code> is a very brief description of your change, and
<codeclass="literal">{long description}</code> is an optional clarifying description. As a rare
exception, if there is no clear component, or your change affects many
components, then the <codeclass="literal">{component}</code> part is optional. See <aclass="link"href="index.xhtml#sec-guidelines-ex-commit-message"title="Example Commit">example commit
</code></pre><p>Similarly, if you are contributing to <spanclass="strong"><strong>nvf</strong></span>, you would include the scope of
the commit followed by the description:</p><pre><codeclass="programlisting">languages/ruby: init module
Adds a language module for Ruby, adds appropriate formatters and Treesitter grammers
</code></pre><p>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.</p><p>Finally, when adding a new module, say <codeclass="literal">modules/foo.nix</code>, we use the fixed
commit format <codeclass="literal">foo: add module</code>. You can, of course, still include a long
description if you wish.</p><p>In case of nested modules, i.e <codeclass="literal">modules/languages/java.nix</code> you are recommended
to contain the parent as well - for example <codeclass="literal">languages/java: some major change</code>.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-guidelines-code-style"class="title"style="clear: both">Code Style </h2></div></div></div><divclass="section"><divclass="titlepage"><div><div><h3id="sec-code-style-treewide"class="title">Treewide </h3></div></div></div><p>Keep lines at a reasonable width, ideally 80 characters or less. This also applies
to string literals and module descriptions and documentation.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h3id="sec-code-style-nix"class="title">Nix </h3></div></div></div><p><spanclass="strong"><strong>nvf</strong></span> is formatted by the <aclass="link"href="https://github.com/kamadorueda/alejandra"target="_top">alejandra</a>
tool and the formatting is checked in the pull request and push workflows. Run the
<codeclass="literal">nix fmt</code> command inside the project repository before submitting your pull request.</p><p>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.</p><p>Please use one line code for attribute sets that contain only one subset.
</code></pre><p>If you move a line down after the merge operator, Alejandra will automatically
unfold the whole merged attrset for you, which we <spanclass="strong"><strong>do not</strong></span> want.</p><pre><codeclass="programlisting nix">module = {
</div><divclass="section"><divclass="titlepage"><div><div><h1id="sec-testing-changes"class="title"style="clear: both">Testing Changes </h1></div></div></div><p>Once you have made your changes, you will need to test them throughly. If it is
a module, add your module option to <codeclass="literal">configuration.nix</code> (located in the root of
this project) inside <codeclass="literal">neovimConfiguration</code>. Enable it, and then run the maximal
configuration with <codeclass="literal">nix run .#maximal -Lv</code> to check for build errors. If neovim
opens in the current directory without any error messages (you can check the
output of <codeclass="literal">:messages</code> 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.</p><p>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
<codeclass="literal">configuration.nix</code>, and then run it with <codeclass="literal">nix run .#maximal -Lv</code>. Same procedure
as adding a new module will apply here.</p>
</div><divclass="section"><divclass="titlepage"><div><div><h1id="sec-keybinds"class="title"style="clear: both">Keybinds </h1></div></div></div><divclass="toc"><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-custom-key-mappings">Custom Key Mappings Support for a Plugin</a></span></dt></dl></div><p>As of 0.4, there exists an API for writing your own keybinds and a couple of
useful utility functions are available in the <aclass="link"href="https://github.com/NotAShelf/nvf/tree/main/lib"target="_top">extended standard
library</a>. The following
section contains a general overview to how you may utilize said functions.</p><divclass="section"><divclass="titlepage"><div><div><h2id="sec-custom-key-mappings"class="title"style="clear: both">Custom Key Mappings Support for a Plugin </h2></div></div></div><p>To set a mapping, you should define it in <codeclass="literal">vim.maps.<<mode>></code>.
The available modes are:</p><divclass="itemizedlist"><ulclass="itemizedlist compact"style="list-style-type: disc;"><liclass="listitem"><p>normal</p></li><liclass="listitem"><p>insert</p></li><liclass="listitem"><p>select</p></li><liclass="listitem"><p>visual</p></li><liclass="listitem"><p>terminal</p></li><liclass="listitem"><p>normalVisualOp</p></li><liclass="listitem"><p>visualOnly</p></li><liclass="listitem"><p>operator</p></li><liclass="listitem"><p>insertCommand</p></li><liclass="listitem"><p>lang</p></li><liclass="listitem"><p>command</p></li></ul></div><p>An example, simple keybinding, can look like this:</p><pre><codeclass="programlisting nix">{
to see a list of them.</p><p><spanclass="strong"><strong>nvf</strong></span> provides a list of helper commands, so that you don’t have to write the
mapping attribute sets every time:</p><divclass="itemizedlist"><ulclass="itemizedlist compact"style="list-style-type: disc;"><liclass="listitem"><p><codeclass="literal">mkBinding = key: action: desc:</code> - makes a basic binding, with <codeclass="literal">silent</code> set
to true.</p></li><liclass="listitem"><p><codeclass="literal">mkExprBinding = key: action: desc:</code> - makes an expression binding, with
<codeclass="literal">lua</code>, <codeclass="literal">silent</code>, and <codeclass="literal">expr</code> set to true.</p></li><liclass="listitem"><p><codeclass="literal">mkLuaBinding = key: action: desc:</code> - makes an expression binding, with
<codeclass="literal">lua</code>, and <codeclass="literal">silent</code> set to true.</p></li></ul></div><p>Do note that the Lua in these bindings is actual Lua, and not pasted into a
<codeclass="literal">:lua</code> command. Therefore, you should either pass in a function like
<codeclass="literal">require('someplugin').some_function</code>, without actually calling it, or you
should define your own functions, for example</p><pre><codeclass="programlisting lua">function()
require('someplugin').some_function()
end
</code></pre><p>Additionally, to not have to repeat the descriptions, there’s another utility
function with its own set of functions: Utility function that takes two
</code></pre><p>This function can be used in combination with the same <codeclass="literal">mkBinding</code> functions as
above, except they only take two arguments - <codeclass="literal">binding</code> and <codeclass="literal">action</code>, and have
different names:</p><divclass="itemizedlist"><ulclass="itemizedlist compact"style="list-style-type: disc;"><liclass="listitem"><p><codeclass="literal">mkSetBinding = binding: action:</code> - makes a basic binding, with <codeclass="literal">silent</code>
set to true.</p></li><liclass="listitem"><p><codeclass="literal">mkSetExprBinding = binding: action:</code> - makes an expression binding, with
<codeclass="literal">lua</code>, <codeclass="literal">silent</code>, and <codeclass="literal">expr</code> set to true.</p></li><liclass="listitem"><p><codeclass="literal">mkSetLuaBinding = binding: action:</code> - makes an expression binding, with
<codeclass="literal">lua</code>, and <codeclass="literal">silent</code> set to true.</p></li></ul></div><p>You can read the source code of some modules to see them in action, but their
usage should look something like this:</p><pre><codeclass="programlisting nix"># plugindefinition.nix
</div><divclass="section"><divclass="titlepage"><div><div><h1id="sec-additional-plugins"class="title"style="clear: both">Adding Plugins </h1></div></div></div><divclass="toc"><dlclass="toc"><dt><spanclass="section"><ahref="index.xhtml#sec-modular-setup-options">Modular setup options</a></span></dt><dt><spanclass="section"><ahref="index.xhtml#sec-details-of-toluaobject">Details of toLuaObject</a></span></dt></dl></div><p>To add a new Neovim plugin, first add the source url in the inputs section of <codeclass="literal">flake.nix</code>
with the prefix <codeclass="literal">plugin-</code></p><pre><codeclass="programlisting nix">
</code></pre><p>The addition of the <codeclass="literal">plugin-</code> prefix will allow <spanclass="strong"><strong>nvf</strong></span> 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 <codeclass="literal">lib/types/plugins.nix</code></p><p>You can now reference this plugin using its string name, the plugin will be
built with the name and source URL from the flake input, allowing you to
refer to it as a <spanclass="strong"><strong>string</strong></span>.</p><pre><codeclass="programlisting nix">config.vim.startPlugins = ["neodev-nvim"];
</code></pre><divclass="section"><divclass="titlepage"><div><div><h2id="sec-modular-setup-options"class="title"style="clear: both">Modular setup options </h2></div></div></div><p>Most plugins is initialized with a call to <codeclass="literal">require('plugin').setup({...})</code>.</p><p>We use a special function that lets you easily add support for such setup options in a modular way:
<codeclass="literal">mkPluginSetupOption</code>.</p><p>Once you have added the source of the plugin as shown above, you can define the setup options like
this:</p><pre><codeclass="programlisting nix"># in modules/.../your-plugin/your-plugin.nix
</code></pre><p>This above config will result in this lua script:</p><pre><codeclass="programlisting lua">require('plugin-name').setup({
enable_feature_a = false,
number_option = 3,
})
</code></pre><p>Now users can set any of the pre-defined option field, and can also add their own fields!</p><pre><codeclass="programlisting nix"># in user's config
{
vim.your-plugin.setupOpts = {
enable_feature_a = true;
number_option = 4;
another_field = "hello";
size = { # nested fields work as well
top = 10;
};
};
}
</code></pre>
</div><divclass="section"><divclass="titlepage"><div><div><h2id="sec-details-of-toluaobject"class="title"style="clear: both">Details of toLuaObject </h2></div></div></div><p>As you’ve seen above, <codeclass="literal">toLuaObject</code> is used to convert our nix attrSet
<codeclass="literal">cfg.setupOpts</code>, into a lua table. Here are some rules of the conversion:</p><divclass="orderedlist"><olclass="orderedlist compact"type="1"><liclass="listitem"><p>nix <codeclass="literal">null</code> converts to lua <codeclass="literal">nil</code></p></li><liclass="listitem"><p>number and strings convert to their lua counterparts</p></li><liclass="listitem"><p>nix attrSet/list convert into lua tables</p></li><liclass="listitem"><p>you can write raw lua code using <codeclass="literal">lib.generators.mkLuaInline</code>. This
function is part of nixpkgs.</p></li></ol></div><p>Example:</p><pre><codeclass="programlisting nix">vim.your-plugin.setupOpts = {
