nvf is a highly modular, configurable, extensible and easy to use Neovim
+configuration in Nix. Designed for flexibility and ease of use, nvf allows you
+to easily configure your fully featured Neovim instance with a few lines of Nix.
+
Bugs & Suggestions
If you notice any issues with nvf, or this documentation, then please consider
+reporting them over at the issue tracker. Issues tab, in addition to the
+discussions tab is a good place as any to request new features.
You may also consider submitting bugfixes, feature additions and upstreamed
+changes that you think are critical over at the pull requests tab.
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, two specialized
+configurations are provided:
Nix - Nix language server + simple utility plugins
Maximal - Variable language servers + utility and decorative plugins
You may try out any of the provided configurations using the nix run command
+on a system where Nix is installed.
$ 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 once you garbage collect.
$ nix run github:notashelf/nvf#nix
+$ nix run github:notashelf/nvf#maximal
+
Available Configs
Nix
Nix configuration by default provides LSP/diagnostic support for Nix alongside
+a set of visual and functional plugins. By running nix run .#, which is the
+default package, you will build Neovim with this config.
+
Maximal
Maximal 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.
Tip
You are strongly recommended to use the binary cache if you would like to try
+the Maximal configuration.
+
+
+
+
+
+
+
Default Configs
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.
It is the same fully configured Neovim as with the 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. :::
+
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.
+
+
Installing nvf
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.
It is possible to install nvf without depending on NixOS or Home-Manager as the
+parent module system, using the neovimConfiguration function exposed in the
+extended library. This function will take modules and extraSpecialArgs as
+arguments, and return the following schema as a result.
{
+ options = "The options that were available to configure";
+ config = "The outputted configuration";
+ pkgs = "The package set used to evaluate the module";
+ neovim = "The built neovim package";
+}
+
An example flake that exposes your custom Neovim configuration might look like
{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ nvf.url = "github:notashelf/nvf";
+ };
+
+ outputs = {nixpkgs, ...} @ inputs: {
+ packages.x86_64-linux = {
+ # Set the default package to the wrapped instance of Neovim.
+ # This will allow running your Neovim configuration with
+ # `nix run` and in addition, sharing your configuration with
+ # other users in case your repository is public.
+ default =
+ (inputs.nvf.lib.neovimConfiguration {
+ pkgs = nixpkgs.legacyPackages.x86_64-linux;
+ modules = [
+ {
+ config.vim = {
+ # Enable custom theming options
+ theme.enable = true;
+
+ # Enable Treesitter
+ tree-sitter.enable = true;
+
+ # Other options will go here. Refer to the config
+ # reference in Appendix B of the nvf manual.
+ # ...
+ };
+ }
+ ];
+ })
+ .neovim;
+ };
+ };
+}
+
The above setup will allow to set up nvf as a standalone flake, which you can
+build independently from your system configuration while also possibly sharing
+it with others. The next two chapters will detail specific usage of such a setup
+for a package output in the context of NixOS or Home-Manager installation.
Standalone Installation on NixOS
Your built Neovim 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 extensively.
{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ home-manager.url = "github:nix-community/home-manager";
+ nvf.url = "github:notashelf/nvf";
+ };
+
+ outputs = {
+ nixpkgs,
+ nvf,
+ self,
+ ...
+ }: {
+ # This will make the package available as a flake output under 'packages'
+ packages.x86_64-linux.my-neovim =
+ (nvf.lib.neovimConfiguration {
+ pkgs = nixpkgs.legacyPackages.x86_64-linux;
+ modules = [
+ # Or move this to a separate file and add it's path here instead
+ # IE: ./nvf_module.nix
+ (
+ {pkgs, ...}: {
+ # Add any custom options (and do feel free to upstream them!)
+ # options = { ... };
+ config.vim = {
+ theme.enable = true;
+ # and more options as you see fit...
+ };
+ }
+ )
+ ];
+ })
+ .neovim;
+
+ # Example nixosConfiguration using the configured Neovim package
+ nixosConfigurations = {
+ yourHostName = nixpkgs.lib.nixosSystem {
+ # ...
+ modules = [
+ # This will make wrapped neovim available in your system packages
+ # Can also move this to another config file if you pass inputs/self around with specialArgs
+ ({pkgs, ...}: {
+ environment.systemPackages = [self.packages.${pkgs.stdenv.system}.neovim];
+ })
+ ];
+ # ...
+ };
+ };
+ };
+}```
+
+
Standalone Installation on Home-Manager
Your built Neovim 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 extensively.
{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ home-manager.url = "github:nix-community/home-manager";
+ nvf.url = "github:notashelf/nvf";
+ };
+
+ outputs = {nixpkgs, home-manager, nvf, ...}: let
+ system = "x86_64-linux";
+ pkgs = nixpkgs.legacyPackages.${system};
+ configModule = {
+ # 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 = nvf.lib.neovimConfiguration {
+ inherit pkgs;
+ modules = [configModule];
+ };
+ in {
+ # This will make the package available as a flake output under 'packages'
+ packages.${system}.my-neovim = customNeovim.neovim;
+
+ # Example Home-Manager configuration using the configured Neovim package
+ homeConfigurations = {
+ "your-username@your-hostname" = home-manager.lib.homeManagerConfiguration {
+ # ...
+ modules = [
+ # This will make Neovim available to users using the Home-Manager
+ # configuration. To make the package available to all users, prefer
+ # environment.systemPackages in your NixOS configuration.
+ {home.packages = [customNeovim.neovim];}
+ ];
+ # ...
+ };
+ };
+ };
+}
+
The below chapters will describe installing nvf as NixOS and Home-Manager
+modules. Note that those methods are mutually exclusive, and will likely cause
+path collisions if used simultaneously.
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.
{
+ inputs = {
+ # Optional, if you intend to follow nvf's obsidian-nvim input
+ # you must also add it as a flake input.
+ obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
+
+ # Required, nvf works best and only directly supports flakes
+ nvf = {
+ url = "github:notashelf/nvf";
+ # You can override the input nixpkgs to follow your system's
+ # instance of nixpkgs. This is safe to do as nvf does not depend
+ # on a binary cache.
+ inputs.nixpkgs.follows = "nixpkgs";
+ # Optionally, 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.
{
+ # assuming nvf is in your inputs and inputs is in the argset
+ # see example below
+ imports = [ inputs.nvf.nixosModules.default ];
+}
+
Example Installation
{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ nvf.url = "github:notashelf/nvf";
+ };
+
+ outputs = { nixpkgs, nvf, ... }: {
+ # ↓ this is your host output in the flake schema
+ nixosConfigurations."your-hostname" = nixpkgs.lib.nixosSystem {
+ modules = [
+ nvf.nixosModules.default # <- this imports the NixOS module that provides the options
+ ./configuration.nix # <- your host entrypoint, `programs.nvf.*` may be defined here
+ ];
+ };
+ };
+}
+
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.
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 available options in the
+appendix
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.
{
+ inputs = {
+ # Optional, if you intend to follow nvf's obsidian-nvim input
+ # you must also add it as a flake input.
+ obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
+
+ # Required, nvf works best and only directly supports flakes
+ nvf = {
+ url = "github:notashelf/nvf";
+ # You can override the input nixpkgs to follow your system's
+ # instance of nixpkgs. This is safe to do as nvf does not depend
+ # on a binary cache.
+ inputs.nixpkgs.follows = "nixpkgs";
+ # Optionally, 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 home-manager module somewhere in your configuration.
{
+ # Assuming "nvf" is in your inputs and inputs is in the argument set.
+ # See example installation below
+ imports = [ inputs.nvf.homeManagerModules.default ];
+}
+
Example Installation
{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ home-manager.url = "github:nix-community/home-manager";
+ nvf.url = "github:notashelf/nvf";
+ };
+
+ outputs = { nixpkgs, home-manager, nvf, ... }: {
+ # ↓ this is your home output in the flake schema, expected by home-manager
+ "your-username@your-hostname" = home-manager.lib.homeManagerConfiguration {
+ pkgs = nixpkgs.legacyPackages.x86_64-linux;
+ modules = [
+ nvf.homeManagerModules.default # <- this imports the home-manager module that provides the options
+ ./home.nix # <- your home entrypoint, `programs.nvf.*` may be defined here
+ ];
+ };
+ };
+}
+
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.
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 available options in the
+appendix
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.
{inputs, pkgs, ...}: {
+ # using the neovim-nightly overlay
+ vim.package = inputs.neovim-overlay.packages.${pkgs.system}.neovim;
+}
+
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.
{ pkgs, ...}: {
+ # using the neovim-nightly overlay
+ vim.package = pkgs.neovim-unwrapped;
+}
+
nvf, by default, exposes a wide variety of plugins as module options for
+your convenience 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.
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 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 added, but nvf provides multiple way of configuring any custom
+plugins that you might have added to your configuration.
Configuring
Just making the plugin to your Neovim configuration available might not always
+be enough. In that case, you can write custom lua config using either
+config.vim.lazy.plugins.*.setupOptsconfig.vim.extraPlugins.*.setup or
+config.vim.luaConfigRC.
The first option uses an extended version of lz.n’s PluginSpec. setupModule
+and setupOpt can be used if the plugin uses a require('module').setup(...)
+pattern. Otherwise, the before and after hooks should do what you need.
{
+ config.vim.lazy.plugins = {
+ aerial.nvim = {
+ # ^^^^^^^^^ this name should match the package.pname or package.name
+ package = aerial-nvim;
+
+ setupModule = "aerial";
+ setupOpts = {option_name = false;};
+
+ after = "print('aerial loaded')";
+ };
+ };
+}
+
The second option uses an attribute set, which maps DAG section names to a
+custom type, which has the fields package, after, setup. They allow you to
+set the package of the plugin, the sections its setup code should be after (note
+that the extraPlugins option has its own DAG scope), and the its setup code
+respectively. For example:
The third option also uses an attribute set, but this one is resolved as a DAG
+directly. The attribute names denote the section names, and the values lua code.
+For example:
{
+ # this will create an "aquarium" section in your init.lua with the contents of your custom config
+ # which will be *appended* to the rest of your configuration, inside your init.vim
+ config.vim.luaConfigRC.aquarium = "vim.cmd('colorscheme aquiarum')";
+}
+
Note
One of the greatest strengths of nvf is the ability to order
+snippets of configuration via the DAG system. It will allow specifying positions
+of individual sections of configuration as needed. nvf provides helper functions
+in the extended library, usually under inputs.nvf.lib.nvim.dag that you may
+use.
Please refer to the DAG section in the nvf manual
+to find out more about the DAG system.
+
Lazy Method
As of version 0.7, we exposed an API for configuring lazy-loaded plugins via
+lz.n and lzn-auto-require.
{
+ config.vim.lazy.plugins = {
+ "aerial.nvim" = {
+ package = pkgs.vimPlugins.aerial-nvim;
+ setupModule = "aerial";
+ setupOpts = {
+ option_name = true;
+ };
+ after = ''
+ -- custom lua code to run after plugin is loaded
+ print('aerial loaded')
+ '';
+
+ # Explicitly mark plugin as lazy. You don't need this if you define one of
+ # the trigger "events" below
+ lazy = true;
+
+ # load on command
+ cmd = ["AerialOpen"];
+
+ # load on event
+ event = ["BufEnter"];
+
+ # load on keymap
+ keys = [
+ {
+ key = "<leader>a";
+ action = ":AerialToggle<CR>";
+ }
+ ];
+ };
+ };
+}
+
+
Non-lazy 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:
Prior to version v0.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
To add a plugin not available in nvf as a module to your configuration, you may
+add it to vim.startPlugins in order to make it available to Neovim at
+runtime.
{pkgs, ...}: {
+ # Add a Neovim plugin from Nixpkgs to the runtime.
+ vim.startPlugins = [pkgs.vimPlugins.aerial-nvim];
+}
+
And to configure the added plugin, you can use the luaConfigRC option to
+provide configuration as a DAG using the nvf extended library.
{inputs, ...}: let
+ # This assumes you have an input called 'nvf' in your flake inputs
+ # and 'inputs' in your specialArgs. In the case you have passed 'nvf'
+ # to specialArgs, the 'inputs' prefix may be omitted.
+ inherit (inputs.nvf.lib.nvim.dag) entryAnywhere;
+in {
+ vim.luaConfigRC.aerial-nvim= entryAnywhere ''
+ require('aerial').setup {
+ -- your configuration here
+ }
+ '';
+}
+
+
+
+
+
+
+
Overriding plugins
The additional plugins section details the addition
+of new plugins to nvf under regular circumstances, i.e. while making a pull
+request to the project. You may override those plugins in your config
+to change source versions, e.g., to use newer versions of plugins
+that are not yet updated in nvf.
vim.pluginOverrides = {
+ lazydev-nvim = pkgs.fetchFromGitHub {
+ owner = "folke";
+ repo = "lazydev.nvim";
+ rev = "";
+ hash = "";
+ };
+ # It's also possible to use a flake input
+ lazydev-nvim = inputs.lazydev-nvim;
+ # Or a local path
+ lazydev-nvim = ./lazydev;
+ # Or a npins pin... etc
+};
+
This will override the source for the neodev.nvim plugin that is used in nvf
+with your own plugin.
Warning
While updating plugin inputs, make sure that any configuration that has been
+deprecated in newer versions is changed in the plugin’s setupOpts. If you
+depend on a new version, requesting a version bump in the issues section is a
+more reliable option.
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.
Adding support for more languages, and improving support for existing ones are
+great places where you can contribute with a PR.
LSP Custom Packages/Command
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:
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"];
+ };
+}
+
We conform to the NixOS options types for the most part, however, a noteworthy
+addition for certain options is the
+DAG (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 luaConfigRC.
The below section, mostly taken from the
+home-manager manual
+explains in more detail the overall usage logic of the DAG type.
entryAnywhere
lib.dag.entryAnywhere (value: T) : DagEntry<T>
Indicates that value can be placed anywhere within the DAG. This is also the
+default for plain attribute set entries, that is
foo.bar = {
+ a = lib.dag.entryAnywhere 0;
+}
+
and
foo.bar = {
+ a = 0;
+}
+
are equivalent.
+
entryAfter
lib.dag.entryAfter (afters: list string) (value: T) : DagEntry<T>
Indicates that value must be placed after each of the attribute names in the
+given list. For example
foo.bar = {
+ a = 0;
+ b = lib.dag.entryAfter [ "a" ] 1;
+}
+
would place b after a in the graph.
+
entryBefore
lib.dag.entryBefore (befores: list string) (value: T) : DagEntry<T>
Indicates that value must be placed before each of the attribute names in
+the given list. For example
foo.bar = {
+ b = lib.dag.entryBefore [ "a" ] 1;
+ a = 0;
+}
+
would place b before a in the graph.
+
entryBetween
lib.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T>
Indicates that value must be placed before the attribute names in the first
+list and after the attribute names in the second list. For example
foo.bar = {
+ a = 0;
+ c = lib.dag.entryBetween [ "b" ] [ "a" ] 2;
+ b = 1;
+}
+
would place c before b and after a in the graph.
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 tag as argument and the DAG entries will be named
+${tag}-${index}.
lib.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
+The list of values are placed are placed after each of the attribute names in
+afters. For example
foo.bar =
+ { b = 0; } // lib.dag.entriesAfter "a" [ "b" ] [ 1 2 ];
+
lib.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
+The list of values are placed before each of the attribute names in befores.
+For example
foo.bar =
+ { b = 0; } // lib.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
+
lib.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
+The list of values are placed before each of the attribute names in befores
+and after each of the attribute names in afters. For example
foo.bar =
+ { b = 0; c = 3; } // lib.dag.entriesBetween "a" [ "b" ] [ "c" ] [ 1 2 ];
+
From the previous chapter, it should be clear that DAGs are useful, because you
+can add code that relies on other code. However, if you don’t know what the
+entries are called, it’s hard to do that, so here is a list of the internal
+entries in nvf:
vim.luaConfigRC (top-level DAG)
(luaConfigPre) - not a part of the actual DAG, instead, it’s simply
+inserted before the rest of the DAG
globalsScript - used to set globals defined in vim.globals
basic - used to set basic configuration options
optionsScript - used to set options defined in vim.o
theme (this is simply placed before pluginConfigs and lazyConfigs,
+meaning that surrounding entries don’t depend on it) - used to set up the
+theme, which has to be done before other plugins
lazyConfigs - lz.n and lzn-auto-require configs. If vim.lazy.enable
+is false, this will contain each plugin’s config instead.
pluginConfigs - the result of the nested vim.pluginRC (internal option,
+see the Custom Plugins page for adding your
+own plugins) DAG, used to set up internal plugins
extraPluginConfigs - the result of vim.extraPlugins, which is not a
+direct DAG, but is converted to, and resolved as one internally
We recognize that you might not always want to configure your setup purely in
+Nix, sometimes doing things in Lua is simply the “superior” option. In such a
+case you might want to configure your Neovim instance using Lua, and nothing but
+Lua. It is also possible to mix Lua and Nix configurations.
Pure Lua or hybrid Lua/Nix configurations can be achieved in two different ways.
+Purely, by modifying Neovim’s runtime directory or impurely by placing Lua
+configuration in a directory found in $HOME. For your convenience, this
+section will document both methods as they can be used.
Pure Runtime Directory
As of 0.6, nvf allows you to modify Neovim’s runtime path to suit your needs.
+One of the ways the new runtime option is to add a configuration located
+relative to your flake.nix, which must be version controlled in pure flakes
+manner.
{
+ # Let us assume we are in the repository root, i.e., the same directory as the
+ # flake.nix. For the sake of the argument, we will assume that the Neovim lua
+ # configuration is in a nvim/ directory relative to flake.nix.
+ vim = {
+ additionalRuntimeDirectories = [
+ # This will be added to Neovim's runtime paths. Conceptually, this behaves
+ # very similarly to ~/.config/nvim but you may not place a top-level
+ # init.lua to be able to require it directly.
+ ./nvim
+ ];
+ };
+}
+
This will add the nvim directory, or rather, the store path that will be
+realised after your flake gets copied to the Nix store, to Neovim’s runtime
+directory. You may now create a lua/myconfig directory within this nvim
+directory, and call it with vim.luaConfigRC.
{pkgs, ...}: {
+ vim = {
+ additionalRuntimeDirectories = [
+ # You can list more than one file here.
+ ./nvim-custom-1
+
+ # To make sure list items are ordered, use lib.mkBefore or lib.mkAfter
+ # Simply placing list items in a given order will **not** ensure that
+ # this list will be deterministic.
+ ./nvim-custom-2
+ ];
+
+ startPlugins = [pkgs.vimPlugins.gitsigns];
+
+ # Neovim supports in-line syntax highlighting for multi-line strings.
+ # Simply place the filetype in a /* comment */ before the line.
+ luaConfigRC.myconfig = /* lua */ ''
+ -- Call the Lua module from ./nvim/lua/myconfig
+ require("myconfig")
+
+ -- Any additional Lua configuration that you might want *after* your own
+ -- configuration. For example, a plugin setup call.
+ require('gitsigns').setup({})
+ '';
+ };
+}
+
+
Impure Absolute Directory
As of Neovim 0.9, $NVIM_APPNAME is a variable expected by Neovim to
+decide on the configuration directory. nvf sets this variable as "nvf",
+meaning ~/.config/nvf will be regarded as the configuration directory by
+Neovim, similar to how ~/.config/nvim behaves in regular installations. This
+allows some degree of Lua configuration, backed by our low-level wrapper
+mnw. Creating a lua/ directory located in
+$NVIM_APPNAME (“nvf” by default) and placing your configuration in, e.g.,
+~/.config/nvf/lua/myconfig will allow you to require it as a part of the Lua
+module system through nvf’s module system.
Let’s assume your ~/.config/nvf/lua/myconfig/init.lua consists of the
+following:
The following Nix configuration via vim.luaConfigRC will allow loading
+this
{
+ # The attribute name "myconfig-dir" here is arbitrary. It is required to be
+ # a *named* attribute by the DAG system, but the name is entirely up to you.
+ vim.luaConfigRC.myconfig-dir = ''
+ require("myconfig")
+
+ -- Any additional Lua
+ '';
+}
+
After you load your custom configuration, you may use an init.lua located in
+your custom configuration directory to configure Neovim exactly as you would
+without a wrapper like nvf. If you want to place your require call in a
+specific position (i.e., before or after options you set in nvf) the
+DAG system will let you place your configuration in a location of your
+choosing.
There may be instances where the your Nix configuration evaluates to invalid
+Lua, or times when you will be asked to provide your built Lua configuration for
+easier debugging by nvf maintainers. nvf provides two helpful utilities out of
+the box.
nvf-print-config and nvf-print-config-path will be bundled with nvf as
+lightweight utilities to help you view or share your built configuration when
+necessary.
To view your configuration with syntax highlighting, you may use the
+bat pager.
nvf-print-config | bat --language=lua
+
Alternatively, cat or less may also be used.
Accessing neovimConfig
It is also possible to access the configuration for the wrapped package. The
+built Neovim package will contain a neovimConfig attribute in its
+passthru.
+
+
+
Offline Documentation
The manpages provided by nvf contains an offline version of the option search
+normally available at https://notashelf.github.io/nvf/options.html. You may
+use the man 5 nvf command to view option documentation from the comfort of
+your terminal.
Note that this is only available for NixOS and Home-Manager module
+installations.
nvf is designed for the developer as much as it is designed for the end-user. We
+would like for any contributor to be able to propagate their changes, or add new
+features to the project with minimum possible friction. As such, below are the
+guides and guidelines written to streamline the contribution process and to
+ensure that your valuable input integrates into nvf’s development as seamlessly
+as possible without leaving any question marks in your head.
This section is directed mainly towards those who wish to contribute code into
+the project. If you instead wish to report a bug, or discuss a potential new
+feature implementation (which you do not wish to implement yourself) first look
+among the already open issues and if no matching issue exists you may open a
+new issue 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. If you wish to make a contribution, but feel stuck -
+please do not be afraid to submit a pull request, we will help you get it in.
Getting Started
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 for
+instructions on how you can do this. Once you have a fork of nvf, you should
+create a separate branch based on the most 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 our
+Contributing Guidelines, push the branch to GitHub and
+create 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.
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 ideally (but not
+necessarily) before you start developing.
Adding Documentation
Almost all changes warrant updates to the documentation: at the very least, you
+must update the changelog. Both the manual and module options use
+Nixpkgs Flavoured Markdown.
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:
Make sure your code is formatted as described in
+code-style section. To maintain consistency
+throughout the project you are encouraged to browse through existing code and
+adopt its style also in new code.
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, 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
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 for a commit message
+that fulfills these requirements.
starship: allow running in Emacs if vterm is used
+
+The vterm buffer is backed by libvterm and can handle Starship prompts
+without issues.
+
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, adds appropriate formatters and Treesitter grammars
+
Long description can be omitted 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.
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
Treewide
Keep lines at a reasonable width, ideally 80 characters or less. This also
+applies to string literals and module descriptions and documentation.
+
Nix
nvf is formatted by the 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:
# parent modules should always be unfolded
+# which means module = { value = ... } instead of module.value = { ... }
+module = {
+ value = mkEnableOption "some description" // { default = true; }; # merges can be done inline where possible
+
+ # same as parent modules, unfold submodules
+ subModule = {
+ # this is an option that contains more than one nested value
+ # Note: try to be careful about the ordering of `mkOption` arguments.
+ # General rule of thumb is to order from least to most likely to change.
+ # This is, for most cases, type < default < description.
+ # Example, if present, would be between default and description
+ someOtherValue = mkOption {
+ type = lib.types.bool;
+ default = true;
+ description = "Some other description";
+ };
+ };
+}
+
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.
module = {
+ key = mkEnableOption "some description" // {
+ default = true; # we want this to be inline
+ }; # ...
+}
+
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.
# this is ok
+acceptableList = [
+ item1 # comment
+ item2
+ item3 # some other comment
+ item4
+];
+
+# this is not ok
+listToBeAvoided = [item1 item2 /* comment */ item3 item4];
+
+# this is ok
+acceptableList = [item1 item2];
+
+# this is also ok if the list is expected to contain more elements
+acceptableList= [
+ item1
+ item2
+ # more items if needed...
+];
+
+
+
+
+
+
Testing Changes
Once you have made your changes, you will need to test them thoroughly. 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 possible.
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.
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. The
+following section contains a general overview to how you may utilize said
+functions.
Custom Key Mappings Support for a Plugin
To set a mapping, you should define it in vim.keymaps.
An example, simple keybinding, can look like this:
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.
Below are the module options provided by nvf, in no particular order. Most
+options will include useful comments, warnings or setup tips on how a module
+option is meant to be used as well as examples in complex cases.
An offline version of this page is bundled with nvf as a part of the manpages
+which you can access with man 5 nvf. Please us know if you believe any of the
+options below are missing useful examples.
Additional arguments passed to each module in addition to ones
+like lib, config,
+and pkgs, modulesPath.
This option is also available to all submodules. Submodules do not
+inherit args from their parent module, nor do they provide args to
+their parent module or sibling submodules. The sole exception to
+this is the argument name which is provided by
+parent modules to a submodule and contains the attribute name
+the submodule is bound to, or a unique generated name if it is
+not bound to an attribute.
Some arguments are already passed by default, of which the
+following cannot be changed with this option:
lib: The nixpkgs library.
config: The results of all options after merging the values from all modules together.
options: The options declared in all modules.
specialArgs: The specialArgs argument passed to evalModules.
All attributes of specialArgs
Whereas option values can generally depend on other option values
+thanks to laziness, this does not apply to imports, which
+must be computed statically before anything else.
For this reason, callers of the module system can provide specialArgs
+which are available during import resolution.
For NixOS, specialArgs includes
+modulesPath, which allows you to import
+extra modules from the nixpkgs package tree without having to
+somehow make the module aware of the location of the
+nixpkgs or NixOS directories.
the experimental Lua module loader to speed up the start up process
If true, this will enable the experimental Lua module loader which:
overrides loadfile
adds the lua loader using the byte-compilation cache
adds the libs loader
removes the default Neovim loader
Note
The Lua module loader is disabled by default. Before setting this option, please
+take a look at the [official documentation]. This option may be enabled by
+default in the future.
Additional runtime paths that will be appended to the
+active runtimepath of the Neovim. This can be used to
+add additional lookup paths for configs, plugins, spell
+languages and other things you would generally place in
+your $HOME/.config/nvim.
This is meant as a declarative alternative to throwing
+files into ~/.config/nvim and having the Neovim
+wrapper pick them up. For more details on
+vim.o.runtimepath, and what paths to use; please see
+the official documentation
+
+
Type:
+list of (absolute path or string)
+
+
Default:
+[ ]
+
+
Example:
[
+ # absolute path, as a string - impure
+ "$HOME/.config/nvim-extra"
+
+ # relative path, as a path - pure
+ ./nvim
+
+ # source type path - pure and reproducible
+ (builtins.source {
+ path = ./runtime;
+ name = "nvim-runtime";
+ })
+]
+
+
A list of Neovim autogroups, which are used to organize and manage related
+autocommands together. Groups allow multiple autocommands to be cleared
+or redefined collectively, preventing duplicate definitions.
Each autogroup consists of a name, a boolean indicating whether to clear
+existing autocommands, and a list of associated autocommands.
The comparator functions used for sorting completions.
You can either pass a valid inline lua function
+(see :help cmp-config.sorting.comparators),
+or a string, in which case the builtin comparator with that name will
+be used.
A deprio function and a kinds
+(require("cmp.types").lsp.CompletionItemKind) variable is provided
+above setupOpts. By passing a type to the function, the returned
+function will be a comparator that always ranks the specified kind the
+lowest.
Map of filetype to formatters. This option takes a set of
+key = value format where the value will be converted
+to its Lua equivalent. You are responsible for passing the
+correct Nix data types to generate a correct Lua value that
+conform is able to accept.
Additional lua files that will be sourced by Neovim.
+Takes both absolute and relative paths, all of which
+will be called via the luafile command in Neovim.
See lua-commands
+on the Neovim documentation for more details.
Warning
All paths passed to this option must be valid. If Neovim cannot
+resolve the path you are attempting to source, then your configuration
+will error, and Neovim will not start. Please ensure that all paths
+are correct before using this option.
+
+
Type:
+list of (absolute path or string)
+
+
Default:
+[ ]
+
+
Example:
[
+ # absolute path, as a string - impure
+ "$HOME/.config/nvim/my-lua-file.lua"
+
+ # relative path, as a path - pure
+ ./nvim/my-lua-file.lua
+
+ # source type path - pure and reproducible
+ (builtins.path {
+ path = ./nvim/my-lua-file.lua;
+ name = "my-lua-file";
+ })
+]
+
+
Change the default window picker, can be a string "default" or a function.
+The function should return the window id that will open the node,
+or nil if an invalid window is picked or user cancelled the action.
The picker may create a new window.
+
+
Type:
+string
+
+
Default:
+"default"
+
+
Example:
-- with s1n7ax/nvim-window-picker plugin
+require('window-picker').pick_window,
+
+
A boolean value that toggle the use of system clipboard when copy/paste
+function are invoked. When enabled, copied text will be stored in registers
+‘+’ (system), otherwise, it will be stored in ‘1’ and ‘"’.
Will use file system watcher (libuv fs_event) to watch the filesystem for changes.
+Using this will disable BufEnter / BufWritePost events in nvim-tree which
+were used to update the whole tree. With this feature, the tree will be
+updated only for the appropriate folder change, resulting in better
+performance.
List of vim regex for absolute directory paths that will not be watched.
+Backslashes must be escaped e.g. "my-project/\\.build$".
+Useful when path is not in .gitignore or git integration is disabled.
Enable the hijack_directories feature. Disable this option if you use vim-dirvish or dirbuf.nvim.
+If hijack_netrw and disable_netrw are false, this feature will be disabled.
Configurations for the live_filtering feature.
+The live filter allows you to filter the tree nodes dynamically, based on
+regex matching (see vim.regex).
+This feature is bound to the f key by default.
+The filter can be cleared with the F key by default.
Enable file highlight for git attributes using NvimTreeGit highlight groups.
+Requires nvimTree.git.enable
+This can be used with or without the icons.
In what format to show root folder. See :help filename-modifiers for
+available string options.
+Set to false to hide the root folder.
Function is passed the absolute path of the root folder and should
+return a string. e.g.
+my_root_folder_label = function(path)
+return “…/” … vim.fn.fnamemodify(path, “:t”)
+end
List of buffer names and filetypes that will not update the root dir
+of the tree if the file isn’t found under the current root directory.
+Only relevant when update_focused_file.update_root and
+update_focused_file.enable are true.
Update the root directory of the tree if the file is not under current
+root directory. It prefers vim’s cwd and root_dirs.
+Otherwise it falls back to the folder containing the file.
+Only relevant when update_focused_file.enable is true
Show the line number relative to the line with the cursor in front of each line.
+If the option view.number is also true, the number on the cursor line
+will be the line number instead of 0.
Map of filetype to formatters. This option takes a set of
+key = value format where the value will be converted
+to its Lua equivalent. You are responsible for passing the
+correct Nix data types to generate a correct Lua value that
+conform is able to accept.
A freeform attribute set containing global variable values for setting vim
+variables as early as possible. If populated, this option will set vim variables
+in the built luaConfigRC as the first item.
Note
{foo = "bar";} will set vim.g.foo to “bar”, where the type of bar in the
+resulting Lua value will be inferred from the type of the value in the
+{name = value;} pair passed to the option.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to patch flutter-tools so that it doesn’t resolve
+symlinks when detecting flutter path.
This is required if you want to use a flutter package built with nix.
+If you are using a flutter SDK installed from a different source
+and encounter the error “dart missing from PATH”, disable this option.
The entirety of Julia is bundled with nvf, if you enable this
+option, since there is no way to provide only the LSP server.
If you want to avoid that, you have to change
+vim.languages.julia.lsp.package to use the Julia binary
+in PATH (set it to null), and add the LanguageServer package to
+Julia in your devshells.
Remove the ‘F’ flag from shortmess to allow messages to be shown. Without doing this, autocommands that deal with filetypes prohibit messages from being shown
if set to true, the filetype of the otterbuffers will be set. Other wide only
+the autocommand of lspconfig that attaches the language server will be
+executed without setting the filetype
write <path>.otter.<embedded language extension> files to disk on save of main buffer.
+Useful for some linters that require actual files.
+Otter files are deleted on quit or main buffer close
:h events that cause the diagnostic to update.
+Set to: {“BufWritePost”, “InsertLeave”, “TextChanged” }
+for less performant but more instant diagnostic updates
Verbatim lua code that will be inserted before
+the result of luaConfigRc DAG has been resolved.
This option does not take a DAG set, but a string
+instead. Useful when you’d like to insert contents
+of lua configs after the DAG result.
Warning
You do not want to override this option with mkForce
+It is used internally to set certain options as early
+as possible and should be avoided unless you know what
+you’re doing. Passing a string to this option will
+merge it with the default contents.
+
+
Type:
+string
+
+
Default:
+By default, this option will append paths in
+vim.additionalRuntimePaths
+to the runtimepath and enable the experimental Lua module loader
+if vim.enableLuaLoader is set to true.
If this option is passed as a DAG, it will be resolved
+according to the DAG resolution rules (e.g. entryBefore
+or entryAfter) as per the nvf extended library.
+
+
Type:
+(DAG of strings concatenated with “\n”) or string
+
+
Default:
+{ }
+
+
Example:
-- Set the tab size to 4 spaces
+vim.opt.tabstop = 4
+vim.opt.shiftwidth = 4
+vim.opt.expandtab = true
+
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
This option has the same type definition as vim.startPlugins
+and plugins in this list are appended to vim.startPlugins by
+the wrapper during the build process.
To avoid overriding packages and dependencies provided by startPlugins, you
+are recommended to use this option or vim.extraPlugins option.
A freeform attribute set containing vim options to be set as early as possible.
+If populated, this option will set vim options in the built luaConfigRC
+after basic and before pluginConfigs DAG entries.
Note
{foo = "bar";} will set vim.o.foo to “bar”, where the type of bar in the
+resulting Lua value will be inferred from the type of the value in the
+{name = value;} pair passed to the option.
This option takes a string to ensure proper conversion to the corresponding Lua type.
+As such, we do not check the value passed to this option. Please ensure that any value
+that is set here is a valid value as per neovim documentation.
Define what to do when Neovim is started without arguments.
Takes either one of "Disabled", "CurrentDir", "LastSession in which case the value
+will be inserted into sm.AutoloadMode.<value>, or an inline Lua value.
+
+
Type:
+one of “Disabled”, “CurrentDir”, “LastSession” or (luaInline)
Additional words to be used for spellchecking. The names of each key will be
+used as the language code for the spell file. For example
"en.utf-8" = [ ... ];
+
will result in en.utf-8.add.spl being added to Neovim’s runtime in the
+spell directory.
Warning
The attribute keys must be in "<name>.<encoding>" format for Neovim to
+compile your spellfiles without mangling the resulting file names. Please
+make sure that you enter the correct value, as nvf does not do any kind of
+internal checking. Please see :help mkspell for more details.
Example:
# "en" is the name, and "utf-8" is the encoding. For most use cases, utf-8
+# will be enough, however, you may change it to any encoding format Neovim
+# accepts, e.g., utf-16.
+"en.utf-8" = ["nvf" "word_you_want_to_add"];
+=> $out/spell/en-utf-8.add.spl
+
Note that while adding a new language, you will still need to add the name of
+the language (e.g. “en”) to the vim.spellcheck.languages list by name
+in order to enable spellchecking for the language. By default only "en" is in
+the list.
A list of languages that should be used for spellchecking.
To add your own language files, you may place your spell directory in either
+$XDG_CONFIG_HOME/nvf or in a path that is included in the
+additionalRuntimePaths list provided by nvf.
[
+ ''
+ {
+ -- Lsp server name
+ function()
+ local buf_ft = vim.api.nvim_get_option_value('filetype', {})
+
+ -- List of buffer types to exclude
+ local excluded_buf_ft = {"toggleterm", "NvimTree", "neo-tree", "TelescopePrompt"}
+
+ -- Check if the current buffer type is in the excluded list
+ for _, excluded_type in ipairs(excluded_buf_ft) do
+ if buf_ft == excluded_type then
+ return ""
+ end
+ end
+
+ -- Get the name of the LSP server active in the current buffer
+ local clients = vim.lsp.get_active_clients()
+ local msg = 'No Active Lsp'
+
+ -- if no lsp client is attached then return the msg
+ if next(clients) == nil then
+ return msg
+ end
+
+ for _, client in ipairs(clients) do
+ local filetypes = client.config.filetypes
+ if filetypes and vim.fn.index(filetypes, buf_ft) ~= -1 then
+ return client.name
+ end
+ end
+
+ return msg
+ end,
+ icon = ' ',
+ separator = {left = ''},
+ }
+ ''
+ ''
+ {
+ "diagnostics",
+ sources = {'nvim_lsp', 'nvim_diagnostic', 'nvim_diagnostic', 'vim_lsp', 'coc'},
+ symbols = {error = ' ', warn = ' ', info = ' ', hint = ' '},
+ colored = true,
+ update_in_insert = false,
+ always_visible = false,
+ diagnostics_color = {
+ color_error = { fg = 'red' },
+ color_warn = { fg = 'yellow' },
+ color_info = { fg = 'cyan' },
+ },
+ }
+ ''
+]
+
This will be called a lot, so you are encouraged to keep it as
+short and lightweight as possible unless you are fully aware
+of the performance implications.
+
+
Type:
+null or (luaInline)
+
+
Default:
+null
+
+
Example:
custom_filter = function(buf_number, buf_numbers)
+ -- filter out filetypes you don't want to see
+ if vim.bo[buf_number].filetype ~= "<i-dont-want-to-see-this>" then
+ return true
+ end
+ -- filter out by buffer name
+ if vim.fn.bufname(buf_number) ~= "<buffer-name-I-dont-want>" then
+ return true
+ end
+ -- filter out based on arbitrary rules
+ -- e.g. filter out vim wiki buffer from tabline in your work repo
+ if vim.fn.getcwd() == "<work-repo>" and vim.bo[buf_number].filetype ~= "wiki" then
+ return true
+ end
+ -- filter out by it's index number in list (don't show first buffer)
+ if buf_numbers[1] ~= buf_number then
+ return true
+ end
+end
+
+
Function to get the diagnostics indicator.
+The function should return a string to be used as the indicator.
Can be set to nil to keep the buffer name highlight, but delete the
+highlighting.
+
+
Type:
+null or (luaInline)
+
+
Default:
{
+ _type = "lua-inline";
+ expr = ''
+ function(count, level, diagnostics_dict, context)
+ local s = " "
+ for e, n in pairs(diagnostics_dict) do
+ local sym = e == "error" and " "
+ or (e == "warning" and " " or " " )
+ s = s .. n .. sym
+ end
+ return s
+ end
+ '';
+}
+
Whether to update diagnostics while in insert mode.
Setting this to true has performance implications, but they may be
+negligible depending on your setup. Set it to true if you know what
+you are doing.
Defines the command that will be used for live_grep and grep_string pickers.
+Make sure that color is set to never because telescope does not yet interpret color codes.
Supported themes can be found in supportedThemes.nix.
+Setting the theme to “base16” enables base16 theming and
+requires all of the colors in vim.theme.base16-colors to be set.
For languages already supported by nvf, you may
+use the vim.language.<lang>.treesitter options, which
+will automatically add the required grammars to this.
Setting this to true will run :h syntax and tree-sitter at the same time.
+You may this to true if you depend on ‘syntax’ being enabled (like for
+indentation).
Note
Using this option may slow down your editor, and you may see some duplicate
+highlights.
List of treesitter grammars to disable highlighting for.
This option can be either a list, in which case it will be
+converted to a Lua table containing grammars to disable
+highlighting for, or a string containing a lua function
+that will be read as is.
Warning
A comma will be added at the end of your function, so you
+do not need to add it yourself. Doing so will cause in
+syntax errors within your Neovim configuration.
+
+
Type:
+(list of string) or (luaInline)
+
+
Default:
+[ ]
+
+
Example:
-- Disable slow treesitter highlight for large files
+function(lang, buf)
+ local max_filesize = 1000 * 1024 -- 1MB
+ local ok, stats = pcall(vim.loop.fs_stat, vim.api.nvim_buf_get_name(buf))
+ if ok and stats and stats.size > max_filesize then
+ return true
+ end
+end
+
List of treesitter grammars to disable incremental selection
+for.
This option can be either a list, in which case it will be
+converted to a Lua table containing grammars to disable
+indentation for, or a string containing a lua function
+that will be read as is.
Warning
A comma will be added at the end of your function, so you
+do not need to add it yourself. Doing so will cause in
+syntax errors within your Neovim configuration.
List of treesitter grammars to disable indentation for.
This option can be either a list, in which case it will be
+converted to a Lua table containing grammars to disable
+indentation for, or a string containing a lua function
+that will be read as is.
Warning
A comma will be added at the end of your function, so you
+do not need to add it yourself. Doing so will cause in
+syntax errors within your Neovim configuration.
If a list is given, it should have a length of eight or any divisor of
+eight. The array will specify the eight chars building up the border in
+a clockwise fashion starting with the top-left corner. You can specify
+a different highlight group for each character by passing a
+[char, “YourHighlightGroup”] instead
+
+
Type:
+one of “none”, “single”, “double”, “rounded”, “solid”, “shadow” or list of (string or list of string)
nvim-surround: add/change/delete surrounding delimiter pairs with ease.
+Note that the default mappings deviate from upstream to avoid conflicts
+with nvim-leap.
Configuration used to generate an animation to be registered.
The final value for ca_config will be used to register a new
+animation using require("cellular-automaton").register_animation(ca_config)
Warning
ca_configmust eval to a valid Lua table. nvf does not and cannot
+perform any kind of validation on your Lua code, so bogus values will
+result in errors when the animation is registered.
+
+
Type:
+luaInline
+
+
Default:
{
+ _type = "lua-inline";
+ expr = ''
+ local ca_config = {
+ fps = 50,
+ name = 'slide',
+ }
+
+ -- init function is invoked only once at the start
+ -- config.init = function (grid)
+ --
+ -- end
+
+ -- update function
+ ca_config.update = function (grid)
+ for i = 1, #grid do
+ local prev = grid[i][#(grid[i])]
+ for j = 1, #(grid[i]) do
+ grid[i][j], prev = prev, grid[i][j]
+ end
+ end
+ return true
+ end
+ '';
+}
+
The min_length option defines the minimum number of characters
+a word must have to be highlighted as a “cursor word.” Any word
+shorter than this value will be ignored and not highlighted.
At times, certain plugins and modules may refuse to play nicely with your setup,
+be it a result of generating Lua from Nix, or the state of packaging. This page,
+in turn, will list any known modules or plugins that are known to misbehave, and
+possible workarounds that you may apply.
When working with NodeJS, everything works as expected, but some projects have
+settings that can fool nvf.
If this plugin or similar
+is included, you might get a situation where your eslint configuration diagnoses
+your formatting according to its own config (usually .eslintrc.js).
The issue there is your formatting is made via prettierd.
This results in auto-formatting relying on your prettier config, while your
+eslint config diagnoses formatting
+which it’s not supposed to)
In the end, you get discrepancies between what your editor does and what it
+wants.
Solutions are:
Don’t add a formatting config to eslint, and separate prettier and eslint.
PR this repo to add an ESLint formatter and configure nvf to use it.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs-preview-707/release-notes.html b/docs-preview-707/release-notes.html
new file mode 100644
index 00000000..b38f9392
--- /dev/null
+++ b/docs-preview-707/release-notes.html
@@ -0,0 +1,383 @@
+
+
+
+
+
+ Appendix C. Release Notes
+
+
+
+
+
+
+
+
Removed hare language support (lsp/tree-sitter/etc). vim.lsp.hare is no
+longer defined. If you use hare and would like it added back, please file an
+issue.
vim.startPlugins & vim.optPlugins are now an enum of
+string for options sourced from the flake inputs. Users can still provide
+vim plugin packages.
If you are contributing and adding a new plugin, add the plugin name to
+availablePlugins in [types-plugin.nix].
neovimBuilder has been removed for configuration. Using an overlay is no
+longer required. See the manual for the new way to configuration.
Treesitter grammars are now configurable with
+vim.treesitter.grammars. Utilizes the nixpkgs nvim-treesitter
+plugin rather than a custom input in order to take advantage of build support
+of pinned versions. See the relevant discourse post for more information.
+Packages can be found under the vimPlugins.nvim-treesitter.builtGrammars
+namespace.
vim.configRC and vim.luaConfigRC are now of type DAG lines. This
+allows for ordering of the config. Usage is the same is in home-manager’s
+home.activation option.
Added two minimap plugins under vim.minimap. codewindow.nvim is enabled by
+default, while minimap.vim is available with its code-minimap dependency.
A complementary plugin, obsidian.nvim and the Neovim alternative for Emacs’
+orgmode with orgmode.nvim have been added. Both will be disabled by default.
Smooth scrolling for ANY movement command is now available with
+cinnamon.nvim
You will now notice a dashboard on startup. This is provided by the
+alpha.nvim plugin. You can use any of the three available dashboard plugins,
+or disable them entirely.
There is now a scrollbar on active buffers, which can highlight errors by
+hooking to your LSPs. This is on by default, but can be toggled off under
+vim.visuals if seen necessary.
Discord Rich Presence has been added through presence.nvim for those who
+want to flex that they are using the superior text editor.
An icon picker is now available with telescope integration. You can use
+:IconPickerInsert or :IconPickerYank to add icons to your code.
A general-purpose cheatsheet has been added through cheatsheet.nvim. Forget
+no longer!
ccc.nvim has been added to the default plugins to allow picking colors with
+ease.
Most UI components of Neovim have been replaced through the help of
+noice.nvim. There are also notifications and custom UI elements available
+for Neovim messages and prompts.
A (floating by default) terminal has been added through toggleterm.nvim.
Harness the power of ethical (tabnine.nvim) and not-so-ethical
+(copilot.lua) AI by those new assistant plugins. Both are off by default,
+TabNine needs to be wrapped before it’s working.
Experimental mouse gestures have been added through gesture.nvim. See plugin
+page and the relevant module for more details on how to use.
Re-open last visited buffers via nvim-session-manager. Disabled by default
+as deleting buffers seems to be problematic at the moment.
Most of NvimTree’s configuration options have been changed with some options
+being toggled to off by default.
Lualine had its configuration simplified and style toned down. Less color,
+more info.
Modules where multiple plugin configurations were in the same directory have
+been simplified. Each plugin inside a single module gets its directory to be
+imported.
Separate config options with the same parent attribute have been merged into
+one for simplicity.
Release 0.3 had to come out before I wanted it to due to Neovim 0.9 dropping
+into nixpkgs-unstable. The Treesitter changes have prompted a Treesitter rework,
+which was followed by reworking the languages system. Most of the changes to
+those are downstreamed from the original repository. The feature requests that
+was originally planned for 0.3 have been moved to 0.4, which should come out
+soon.
Changelog
We have transitioned to flake-parts, from flake-utils to extend the
+flexibility of this flake. This means the flake structure is different than
+usual, but the functionality remains the same.
We now provide a home-manager module. Do note that it is still far from
+perfect, but it works.
nodejs_16 is now bundled with Copilot.lua if the user has enabled Copilot
+assistant.
which-key section titles have been fixed. This is to be changed once again in
+a possible keybind rewrite, but now it should display the correct titles
+instead of +prefix
Most of presence.nvim’s options have been made fully configurable through
+your configuration file.
Most of the modules have been refactored to separate config and options
+attributes.
Darwin has been deprecated as the Zig package is marked as broken. We will
+attempt to use the Zig overlay to return Darwin support.
Fidget.nvim has been added as a neat visual addition for LSP installations.
diffview.nvim has been added to provide a convenient diff utility.
Treesitter grammars are now configurable with
+vim.treesitter.grammars. Utilizes the nixpkgs nvim-treesitter
+plugin rather than a custom input in order to take advantage of build support
+of pinned versions. See discourse for more information. Packages can be
+found under the pkgs.vimPlugins.nvim-treesitter.builtGrammars attribute.
+Treesitter grammars for supported languages should be enabled within the
+module. By default no grammars are installed, thus the following grammars
+which do not have a language section are not included anymore: comment,
+toml, make, html, css, graphql, json.
A new section has been added for language support: vim.languages.<language>.
Improved handling of completion formatting. When setting
+vim.autocomplete.sources, can also include optional menu mapping. And can
+provide your own function with vim.autocomplete.formatting.format.
For vim.visuals.indentBlankline.fillChar and
+vim.visuals.indentBlankline.eolChar options, turning them off should be done
+by using null rather than "" now.
Transparency has been made optional and has been disabled by default.
+vim.theme.transparent option can be used to enable or disable
+transparency for your configuration.
Fixed deprecated configuration method for Tokyonight, and added new style
+“moon”
Dart language support as well as extended flutter support has been added.
+Thanks to @FlafyDev for his contributions towards Dart language support.
Elixir language support has been added through elixir-tools.nvim.
hop.nvim and leap.nvim have been added for fast navigation.
modes.nvim has been added to the UI plugins as a minor error highlighter.
smartcollumn.nvim has been added to dynamically display a colorcolumn when
+the limit has been exceeded, providing per-buftype column position and more.
project.nvim has been added for better project management inside Neovim.
More configuration options have been added to nvim-session-manager.
Editorconfig support has been added to the core functionality, with an enable
+option.
venn-nvim has been dropped due to broken keybinds.
Following the release of v0.3, I have decided to release v0.4 with a massive new
+change: customizable keybinds. As of the 0.4 release, keybinds will no longer be
+hardcoded and instead provided by each module’s own keybinds section. The old
+keybind system (vim.keybinds = {}) is now considered deprecated and the new
+lib functions are recommended to be used for adding keybinds for new plugins, or
+adding keybinds to existing plugins.
Alongside customizable keybinds, there are a few quality of life updates, such
+as lazygit integration and the new experimental Lua loader of Neovim 0.9
+thanks to our awesome contributors who made this update possible during my
+absence.
Added lsp_lines plugin for showing diagnostic messages
Added a configuration option for choosing the leader key
The package used for neovim is now customizable by the user, using
+vim.package. For best results, always use an unwrapped package
Added highlight-undo plugin for highlighting undo/redo targets
Added bash LSP and formatter support
Disabled Lualine LSP status indicator for Toggleterm buffer
Added nvim-docs-view, a plugin to display LSP hover documentation in a side
+panel
Switched to nixosOptionsDoc in option documentation. To quote home-manager
+commit: “Output is mostly unchanged aside from some minor typographical and
+formatting changes, along with better source links.”
Updated indent-blankine.nvim to v3 - this comes with a few option changes,
+which will be migrated with renamedOptionModule
In v0.6 we are introducing setupOpts: many plugin related options are moved
+into their respective setupOpts submodule, e.g. nvimTree.disableNetrw is
+renamed to nvimTree.setupOpts.disable_netrw.
Why? in short, you can now pass in anything to setupOpts and it will be passed
+to your require'plugin'.setup{...}. No need to wait for us to support every
+single plugin option.
The warnings when you rebuild your config should be enough to guide you through
+what you need to do, if there’s an option that was renamed but wasn’t listed in
+the warning, please file a bug report!
To make your migration process less annoying, here’s a keybind that will help
+you with renaming stuff from camelCase to snake_case (you’ll be doing that a
+lot):
-- paste this in a temp.lua file and load it in vim with :source /path/to/temp.lua
+function camelToSnake()
+ -- Get the current word under the cursor
+ local word = vim.fn.expand("<cword>")
+ -- Replace each capital letter with an underscore followed by its lowercase equivalent
+ local snakeCase = string.gsub(word, "%u", function(match)
+ return "_" .. string.lower(match)
+ end)
+ -- Remove the leading underscore if present
+ if string.sub(snakeCase, 1, 1) == "_" then
+ snakeCase = string.sub(snakeCase, 2)
+ end
+ vim.fn.setreg(vim.v.register, snakeCase)
+ -- Select the word under the cursor and paste
+ vim.cmd("normal! viwP")
+end
+
+vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap = true, silent = true })
+
Added ChatGPT.nvim, which can be enabled with
+vim.assistant.chatgpt.enable. Do keep in mind that this option
+requires OPENAI_API_KEY environment variable to be set.
Added option vim.luaPackages to wrap neovim with extra Lua packages.
Rewrote the entire fidget.nvim module to include extensive configuration
+options. Option vim.fidget-nvim.align.bottom has been removed in favor of
+vim.fidget-nvim.notification.window.align, which now supports top and
+bottom values. vim.fidget-nvim.align.right has no longer any equivalent
+and also has been removed.
Finished moving to nixosOptionsDoc in the documentation and changelog. All
+documentation options and files are fully free of Asciidoc, and will now use
+Nixpkgs flavored markdown.
Bumped plugin inputs to their latest versions.
Deprecated presence.nvim in favor of neocord. This means
+vim.rich-presence.presence-nvim is removed and will throw a warning if used.
+You are recommended to rewrite your neocord configuration from scratch based
+on the. official documentation
Removed Tabnine plugin due to the usage of imperative tarball downloads. If
+you’d like to see it back, please create an issue.
Added support for css and tailwindcss through
+vscode-language-servers-extracted & tailwind-language-server. Those can be
+enabled through vim.languages.css and vim.languages.tailwind.
Updated all plugin inputs to their latest versions (21.04.2024) - this
+brought minor color changes to the Catppuccin theme.
Moved home-manager module entrypoint to flake/modules and added an
+experimental Nixos module. This requires further testing before it can be
+considered ready for use.
Made lib calls explicit. E.g. lib.strings.optionalString instead of
+lib.optionalString. This is a pattern expected to be followed by all
+contributors in the future.
Added image.nvim for image previews.
The final neovim package is now exposed. This means you can build the neovim
+package that will be added to your package list without rebuilding your system
+to test if your configuration yields a broken package.
Changed the tree structure to distinguish between core options and plugin
+options.
Added plugin auto-discovery from plugin inputs. This is mostly from
+JordanIsaac’s neovim-flake.
+Allows contributors to add plugin inputs with the plugin- prefix to have
+them automatically discovered for the plugin type in lib/types.
Moved internal wrapLuaConfig to the extended library, structured its
+arguments to take luaBefore, luaConfig and luaAfter as strings, which
+are then concatted inside a lua block.
Added vim.luaConfigPre and vim.luaConfigPost for inserting
+verbatim Lua configuration before and after the resolved Lua DAG respectively.
+Both of those options take strings as the type, so you may read the contents
+of a Lua file from a given path.
Added vim.spellchecking.ignoredFiletypes and
+vim.spellChecking.programmingWordlist.enable for ignoring certain filetypes
+in spellchecking and enabling vim-dirtytalk respectively. The previously
+used vim.spellcheck.vim-dirtytalk aliases to the latter option.
Exposed withRuby, withNodeJs, withPython3, and python3Packages from
+the makeNeovimConfig function under their respective options.
Added vim.extraPackages for appending additional packages to the
+wrapper PATH, making said packages available while inside the Neovim session.
Made Treesitter options configurable, and moved treesitter-context to
+setupOpts while it is enabled.
Added vim.notify.nvim-notify.setupOpts.render which takes either a
+string of enum, or a Lua function. The default is “compact”, but you may
+change it according to nvim-notify documentation.
In v0.7 we are removing vim.configRC in favor of making vim.luaConfigRC the
+top-level DAG, and thereby making the entire configuration Lua based. This
+change introduces a few breaking changes:
vim.configRC has been removed, which means that you have to convert all of
+your custom vimscript-based configuration to Lua. As for how to do that, you
+will have to consult the Neovim documentation and your search engine.
After migrating your Vimscript-based configuration to Lua, you might not be
+able to use the same entry names in vim.luaConfigRC, because those have also
+slightly changed. See the new DAG entries in nvf manual for more details.
Why?
Neovim being an aggressive refactor of Vim, is designed to be mainly Lua based;
+making good use of its extensive Lua API. Additionally, Vimscript is slow and
+brings unnecessary performance overhead while working with different
+configuration formats.
+
vim.maps rewrite
Instead of specifying map modes using submodules (e.g., vim.maps.normal), a
+new vim.keymaps submodule with support for a mode option has been
+introduced. It can be either a string, or a list of strings, where a string
+represents the short-name of the map mode(s), that the mapping should be set
+for. See :help map-modes for more information.
vim.lsp.nvimCodeActionMenu removed in favor of vim.ui.fastaction
The nvim-code-action-menu plugin has been archived and broken for a long time,
+so it’s being replaced with a young, but better alternative called
+fastaction.nvim. Simply remove everything set under
+vim.lsp.nvimCodeActionMenu, and set vim.ui.fastaction.enable to true.
Note that we are looking to add more alternatives in the future like
+dressing.nvim and actions-preview.nvim, in case fastaction doesn’t work for
+everyone.
+
type based modules removed
As part of the autocompletion rewrite, modules that used to use a type option
+have been replaced by per-plugin modules instead. Since both modules only had
+one type, you can simply change
nixpkgs-fmt has been archived for a while, and it’s finally being removed in
+favor of nixfmt (more information can be found
+here.
To migrate to nixfmt, simply change vim.languages.nix.format.type to
+nixfmt.
+
leader changes
This has been deprecated in favor of using the more generic vim.globals (you
+can use vim.globals.mapleader to change this instead).
Rust specific keymaps now use maplocalleader instead of localleader by
+default. This is to avoid conflicts with other modules. You can change
+maplocalleader with vim.globals.maplocalleader, but it’s recommended to set
+it to something other than mapleader to avoid conflicts.
+
vim.* changes
Inline with the leader changes, we have removed some
+options that were under vim as convenient shorthands for vim.o.* options.
Warning
As v0.7 features the addition of vim.options, those options are now
+considered as deprecated. You should migrate to the appropriate options in the
+vim.options submodule.
The changes are, in no particular order:
colourTerm, mouseSupport, cmdHeight, updateTime, mapTime,
+cursorlineOpt, splitBelow, splitRight, autoIndent and wordWrap have
+been mapped to their vim.options equivalents. Please see the module
+definition for the updated options.
tabWidth has been removed as it lead to confusing behaviour. You can
+replicate the same functionality by setting shiftwidth, tabstop and
+softtabstop under vim.options as you see fit.
Fix null vim.lsp.mappings generating an error and not being filtered out.
Add basic transparency support for oxocarbon theme by setting the highlight
+group for Normal, NormalFloat, LineNr, SignColumn and optionally
+NvimTreeNormal to none.
Fix broken treesitter-context keybinds in visual mode
Deprecate use of __empty to define empty tables in Lua. Empty attrset are no
+longer filtered and thus should be used instead.
Add dap-go for better dap configurations
Make noice.nvim customizable
Standardize border style options and add custom borders
Remove vim.disableDefaultRuntimePaths in wrapper options.
As nvf uses $NVIM_APP_NAME as of recent changes, we can safely assume any
+configuration in $XDG_CONFIG_HOME/nvf is intentional.
Switch from rust-tools.nvim to the more feature-packed rustaceanvim. This
+switch entails a whole bunch of new features and options, so you are
+recommended to go through rustacean.nvim’s README to take a closer look at its
+features and usage
Add lz.n support and lazy-load some builtin plugins.
Enabled the terminal integration of catppuccin for theming Neovim’s built-in
+terminal (this also affects toggleterm).
Migrate bufferline to setupOpts for more customizability
Use clangd as the default language server for C languages
Expose lib.nvim.types.pluginType, which for example allows the user to
+create abstractions for adding plugins
Migrate indent-blankline to setupOpts for more customizability. While the
+plugin’s options can now be found under indentBlankline.setupOpts, the
+previous iteration of the module also included out of place/broken options,
+which have been removed for the time being. These are:
listChar - this was already unused
fillChar - this had nothing to do with the plugin, please configure it
+yourself by adding vim.opt.listchars:append({ space = '<char>' }) to your
+lua configuration
eolChar - this also had nothing to do with the plugin, please configure it
+yourself by adding vim.opt.listchars:append({ eol = '<char>' }) to your
+lua configuration
Replace vim.lsp.nvimCodeActionMenu with vim.ui.fastaction, see the
+breaking changes section above for more details
Add a setupOpts option to nvim-surround, which allows modifying options that
+aren’t defined in nvf. Move the alternate nvim-surround keybinds to use
+setupOpts.
Remove autopairs.type, and rename autopairs.enable to
+autopairs.nvim-autopairs.enable. The new
+vim.autopairs.nvim-autopairs.enable supports setupOpts format by
+default.
Refactor of nvim-cmp and completion related modules
Deprecate legacy Vimsnip in favor of Luasnip, and integrate
+friendly-snippets for bundled snippets. vim.snippets.luasnip.enable
+can be used to toggle Luasnip.
Add C# support under vim.languages.csharp, with support for both
+omnisharp-roslyn and csharp-language-server.
Add Julia support under vim.languages.julia. Note that the entirety of Julia
+is bundled with nvf, if you enable the module, since there is no way to
+provide only the LSP server.
Add run.nvim support for running code
+using cached commands.
Make Neovim’s configuration file entirely Lua based. This comes with a few
+breaking changes:
vim.configRC has been removed. You will need to migrate your entries to
+Neovim-compliant Lua code, and add them to vim.luaConfigRC instead.
+Existing vimscript configurations may be preserved in vim.cmd functions.
+Please see Neovim documentation on vim.cmd
vim.luaScriptRC is now the top-level DAG, and the internal vim.pluginRC
+has been introduced for setting up internal plugins. See the “DAG entries in
+nvf” manual page for more information.
Rewrite vim.maps, see the breaking changes section above.
Add deno fmt as the default Markdown formatter. This will be enabled
+automatically if you have autoformatting enabled, but can be disabled manually
+if you choose to.
Add vim.extraLuaFiles for optionally sourcing additional lua files in your
+configuration.
Refactor programs.languages.elixir to use lspconfig and none-ls for LSP and
+formatter setups respectively. Diagnostics support is considered, and may be
+added once the credo linter has been added to nixpkgs. A pull request is
+currently open.
Remove vim-tidal and friends.
Clean up Lualine module to reduce theme dependency on Catppuccin, and fixed
+blending issues in component separators.
Add [ts-ereror-translator.nvim] extension of the TS language module, under
+vim.languages.ts.extensions.ts-error-translator to aid with Typescript
+development.
Add neo-tree.nvim as an alternative file-tree plugin. It will be available
+under vim.filetree.neo-tree, similar to nvimtree.
Add nvf-print-config & nvf-print-config-path helper scripts to Neovim
+closure. Both of those scripts have been automatically added to your PATH upon
+using neovimConfig or programs.nvf.enable.
nvf-print-config will display your init.lua, in full.
nvf-print-config-path will display the path to a clone of your
+init.lua. This is not the path used by the Neovim wrapper, but an
+identical clone.
Add vim.ui.breadcrumbs.lualine to allow fine-tuning breadcrumbs behaviour on
+Lualine. Only vim.ui.breadcrumbs.lualine.winbar is supported for the time
+being.
vim.ui.breadcrumbs.lualine.winbar.enable has been added to allow
+controlling the default behaviour of the nvim-navic component on Lualine,
+which used to occupy winbar.lualine_c as long as breadcrumbs are enabled.
Move options that used to set vim.o values (e.g. vim.wordWrap) into
+vim.options as default values. Some are left as they don’t have a direct
+equivalent, but expect a switch eventually.
nvf is a highly modular, configurable, extensible and easy to use Neovim
-configuration in Nix. Designed for flexibility and ease of use, nvf allows you
-to easily configure your fully featured Neovim instance with a few lines of Nix.
-
Bugs & Suggestions
If you notice any issues with nvf, or this documentation, then please consider
-reporting them over at the issue tracker. Issues tab, in addition to the
-discussions tab is a good place as any to request new features.
You may also consider submitting bugfixes, feature additions and upstreamed
-changes that you think are critical over at the pull requests tab.
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, two specialized
-configurations are provided:
Nix - Nix language server + simple utility plugins
Maximal - Variable language servers + utility and decorative plugins
You may try out any of the provided configurations using the nix run command
-on a system where Nix is installed.
$ 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 once you garbage collect.
$ nix run github:notashelf/nvf#nix
-$ nix run github:notashelf/nvf#maximal
-
Available Configs
Nix
Nix configuration by default provides LSP/diagnostic support for Nix alongside
-a set of visual and functional plugins. By running nix run .#, which is the
-default package, you will build Neovim with this config.
-
Maximal
Maximal 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.
Tip
You are strongly recommended to use the binary cache if you would like to try
-the Maximal configuration.
-
-
-
-
-
-
-
Default Configs
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.
It is the same fully configured Neovim as with the 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. :::
-
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.
-
-
Installing nvf
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.
It is possible to install nvf without depending on NixOS or Home-Manager as the
-parent module system, using the neovimConfiguration function exposed in the
-extended library. This function will take modules and extraSpecialArgs as
-arguments, and return the following schema as a result.
{
- options = "The options that were available to configure";
- config = "The outputted configuration";
- pkgs = "The package set used to evaluate the module";
- neovim = "The built neovim package";
-}
-
An example flake that exposes your custom Neovim configuration might look like
{
- inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
- nvf.url = "github:notashelf/nvf";
- };
-
- outputs = {nixpkgs, ...} @ inputs: {
- packages.x86_64-linux = {
- # Set the default package to the wrapped instance of Neovim.
- # This will allow running your Neovim configuration with
- # `nix run` and in addition, sharing your configuration with
- # other users in case your repository is public.
- default =
- (inputs.nvf.lib.neovimConfiguration {
- pkgs = nixpkgs.legacyPackages.x86_64-linux;
- modules = [
- {
- config.vim = {
- # Enable custom theming options
- theme.enable = true;
-
- # Enable Treesitter
- tree-sitter.enable = true;
-
- # Other options will go here. Refer to the config
- # reference in Appendix B of the nvf manual.
- # ...
- };
- }
- ];
- })
- .neovim;
- };
- };
-}
-
The above setup will allow to set up nvf as a standalone flake, which you can
-build independently from your system configuration while also possibly sharing
-it with others. The next two chapters will detail specific usage of such a setup
-for a package output in the context of NixOS or Home-Manager installation.
Standalone Installation on NixOS
Your built Neovim 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 extensively.
{
- inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
- home-manager.url = "github:nix-community/home-manager";
- nvf.url = "github:notashelf/nvf";
- };
-
- outputs = {
- nixpkgs,
- nvf,
- self,
- ...
- }: {
- # This will make the package available as a flake output under 'packages'
- packages.x86_64-linux.my-neovim =
- (nvf.lib.neovimConfiguration {
- pkgs = nixpkgs.legacyPackages.x86_64-linux;
- modules = [
- # Or move this to a separate file and add it's path here instead
- # IE: ./nvf_module.nix
- (
- {pkgs, ...}: {
- # Add any custom options (and do feel free to upstream them!)
- # options = { ... };
- config.vim = {
- theme.enable = true;
- # and more options as you see fit...
- };
- }
- )
- ];
- })
- .neovim;
-
- # Example nixosConfiguration using the configured Neovim package
- nixosConfigurations = {
- yourHostName = nixpkgs.lib.nixosSystem {
- # ...
- modules = [
- # This will make wrapped neovim available in your system packages
- # Can also move this to another config file if you pass inputs/self around with specialArgs
- ({pkgs, ...}: {
- environment.systemPackages = [self.packages.${pkgs.stdenv.system}.neovim];
- })
- ];
- # ...
- };
- };
- };
-}```
-
-
Standalone Installation on Home-Manager
Your built Neovim 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 extensively.
{
- inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
- home-manager.url = "github:nix-community/home-manager";
- nvf.url = "github:notashelf/nvf";
- };
-
- outputs = {nixpkgs, home-manager, nvf, ...}: let
- system = "x86_64-linux";
- pkgs = nixpkgs.legacyPackages.${system};
- configModule = {
- # 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 = nvf.lib.neovimConfiguration {
- inherit pkgs;
- modules = [configModule];
- };
- in {
- # This will make the package available as a flake output under 'packages'
- packages.${system}.my-neovim = customNeovim.neovim;
-
- # Example Home-Manager configuration using the configured Neovim package
- homeConfigurations = {
- "your-username@your-hostname" = home-manager.lib.homeManagerConfiguration {
- # ...
- modules = [
- # This will make Neovim available to users using the Home-Manager
- # configuration. To make the package available to all users, prefer
- # environment.systemPackages in your NixOS configuration.
- {home.packages = [customNeovim.neovim];}
- ];
- # ...
- };
- };
- };
-}
-
The below chapters will describe installing nvf as NixOS and Home-Manager
-modules. Note that those methods are mutually exclusive, and will likely cause
-path collisions if used simultaneously.
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.
{
- inputs = {
- # Optional, if you intend to follow nvf's obsidian-nvim input
- # you must also add it as a flake input.
- obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
-
- # Required, nvf works best and only directly supports flakes
- nvf = {
- url = "github:notashelf/nvf";
- # You can override the input nixpkgs to follow your system's
- # instance of nixpkgs. This is safe to do as nvf does not depend
- # on a binary cache.
- inputs.nixpkgs.follows = "nixpkgs";
- # Optionally, 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.
{
- # assuming nvf is in your inputs and inputs is in the argset
- # see example below
- imports = [ inputs.nvf.nixosModules.default ];
-}
-
Example Installation
{
- inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
- nvf.url = "github:notashelf/nvf";
- };
-
- outputs = { nixpkgs, nvf, ... }: {
- # ↓ this is your host output in the flake schema
- nixosConfigurations."your-hostname" = nixpkgs.lib.nixosSystem {
- modules = [
- nvf.nixosModules.default # <- this imports the NixOS module that provides the options
- ./configuration.nix # <- your host entrypoint, `programs.nvf.*` may be defined here
- ];
- };
- };
-}
-
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.
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 available options in the
-appendix
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.
{
- inputs = {
- # Optional, if you intend to follow nvf's obsidian-nvim input
- # you must also add it as a flake input.
- obsidian-nvim.url = "github:epwalsh/obsidian.nvim";
-
- # Required, nvf works best and only directly supports flakes
- nvf = {
- url = "github:notashelf/nvf";
- # You can override the input nixpkgs to follow your system's
- # instance of nixpkgs. This is safe to do as nvf does not depend
- # on a binary cache.
- inputs.nixpkgs.follows = "nixpkgs";
- # Optionally, 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 home-manager module somewhere in your configuration.
{
- # Assuming "nvf" is in your inputs and inputs is in the argument set.
- # See example installation below
- imports = [ inputs.nvf.homeManagerModules.default ];
-}
-
Example Installation
{
- inputs = {
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
- home-manager.url = "github:nix-community/home-manager";
- nvf.url = "github:notashelf/nvf";
- };
-
- outputs = { nixpkgs, home-manager, nvf, ... }: {
- # ↓ this is your home output in the flake schema, expected by home-manager
- "your-username@your-hostname" = home-manager.lib.homeManagerConfiguration {
- pkgs = nixpkgs.legacyPackages.x86_64-linux;
- modules = [
- nvf.homeManagerModules.default # <- this imports the home-manager module that provides the options
- ./home.nix # <- your home entrypoint, `programs.nvf.*` may be defined here
- ];
- };
- };
-}
-
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.
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 available options in the
-appendix
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.
{inputs, pkgs, ...}: {
- # using the neovim-nightly overlay
- vim.package = inputs.neovim-overlay.packages.${pkgs.system}.neovim;
-}
-
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.
{ pkgs, ...}: {
- # using the neovim-nightly overlay
- vim.package = pkgs.neovim-unwrapped;
-}
-
nvf, by default, exposes a wide variety of plugins as module options for
-your convenience 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.
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 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 added, but nvf provides multiple way of configuring any custom
-plugins that you might have added to your configuration.
Configuring
Just making the plugin to your Neovim configuration available might not always
-be enough. In that case, you can write custom lua config using either
-config.vim.lazy.plugins.*.setupOptsconfig.vim.extraPlugins.*.setup or
-config.vim.luaConfigRC.
The first option uses an extended version of lz.n’s PluginSpec. setupModule
-and setupOpt can be used if the plugin uses a require('module').setup(...)
-pattern. Otherwise, the before and after hooks should do what you need.
{
- config.vim.lazy.plugins = {
- aerial.nvim = {
- # ^^^^^^^^^ this name should match the package.pname or package.name
- package = aerial-nvim;
-
- setupModule = "aerial";
- setupOpts = {option_name = false;};
-
- after = "print('aerial loaded')";
- };
- };
-}
-
The second option uses an attribute set, which maps DAG section names to a
-custom type, which has the fields package, after, setup. They allow you to
-set the package of the plugin, the sections its setup code should be after (note
-that the extraPlugins option has its own DAG scope), and the its setup code
-respectively. For example:
The third option also uses an attribute set, but this one is resolved as a DAG
-directly. The attribute names denote the section names, and the values lua code.
-For example:
{
- # this will create an "aquarium" section in your init.lua with the contents of your custom config
- # which will be *appended* to the rest of your configuration, inside your init.vim
- config.vim.luaConfigRC.aquarium = "vim.cmd('colorscheme aquiarum')";
-}
-
Note
One of the greatest strengths of nvf is the ability to order
-snippets of configuration via the DAG system. It will allow specifying positions
-of individual sections of configuration as needed. nvf provides helper functions
-in the extended library, usually under inputs.nvf.lib.nvim.dag that you may
-use.
Please refer to the DAG section in the nvf manual
-to find out more about the DAG system.
-
Lazy Method
As of version 0.7, we exposed an API for configuring lazy-loaded plugins via
-lz.n and lzn-auto-require.
{
- config.vim.lazy.plugins = {
- "aerial.nvim" = {
- package = pkgs.vimPlugins.aerial-nvim;
- setupModule = "aerial";
- setupOpts = {
- option_name = true;
- };
- after = ''
- -- custom lua code to run after plugin is loaded
- print('aerial loaded')
- '';
-
- # Explicitly mark plugin as lazy. You don't need this if you define one of
- # the trigger "events" below
- lazy = true;
-
- # load on command
- cmd = ["AerialOpen"];
-
- # load on event
- event = ["BufEnter"];
-
- # load on keymap
- keys = [
- {
- key = "<leader>a";
- action = ":AerialToggle<CR>";
- }
- ];
- };
- };
-}
-
-
Non-lazy 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:
Prior to version v0.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
To add a plugin not available in nvf as a module to your configuration, you may
-add it to vim.startPlugins in order to make it available to Neovim at
-runtime.
{pkgs, ...}: {
- # Add a Neovim plugin from Nixpkgs to the runtime.
- vim.startPlugins = [pkgs.vimPlugins.aerial-nvim];
-}
-
And to configure the added plugin, you can use the luaConfigRC option to
-provide configuration as a DAG using the nvf extended library.
{inputs, ...}: let
- # This assumes you have an input called 'nvf' in your flake inputs
- # and 'inputs' in your specialArgs. In the case you have passed 'nvf'
- # to specialArgs, the 'inputs' prefix may be omitted.
- inherit (inputs.nvf.lib.nvim.dag) entryAnywhere;
-in {
- vim.luaConfigRC.aerial-nvim= entryAnywhere ''
- require('aerial').setup {
- -- your configuration here
- }
- '';
-}
-
-
-
-
-
-
-
Overriding plugins
The additional plugins section details the addition
-of new plugins to nvf under regular circumstances, i.e. while making a pull
-request to the project. You may override those plugins in your config
-to change source versions, e.g., to use newer versions of plugins
-that are not yet updated in nvf.
vim.pluginOverrides = {
- lazydev-nvim = pkgs.fetchFromGitHub {
- owner = "folke";
- repo = "lazydev.nvim";
- rev = "";
- hash = "";
- };
- # It's also possible to use a flake input
- lazydev-nvim = inputs.lazydev-nvim;
- # Or a local path
- lazydev-nvim = ./lazydev;
- # Or a npins pin... etc
-};
-
This will override the source for the neodev.nvim plugin that is used in nvf
-with your own plugin.
Warning
While updating plugin inputs, make sure that any configuration that has been
-deprecated in newer versions is changed in the plugin’s setupOpts. If you
-depend on a new version, requesting a version bump in the issues section is a
-more reliable option.
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.
Adding support for more languages, and improving support for existing ones are
-great places where you can contribute with a PR.
LSP Custom Packages/Command
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:
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"];
- };
-}
-
We conform to the NixOS options types for the most part, however, a noteworthy
-addition for certain options is the
-DAG (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 luaConfigRC.
The below section, mostly taken from the
-home-manager manual
-explains in more detail the overall usage logic of the DAG type.
entryAnywhere
lib.dag.entryAnywhere (value: T) : DagEntry<T>
Indicates that value can be placed anywhere within the DAG. This is also the
-default for plain attribute set entries, that is
foo.bar = {
- a = lib.dag.entryAnywhere 0;
-}
-
and
foo.bar = {
- a = 0;
-}
-
are equivalent.
-
entryAfter
lib.dag.entryAfter (afters: list string) (value: T) : DagEntry<T>
Indicates that value must be placed after each of the attribute names in the
-given list. For example
foo.bar = {
- a = 0;
- b = lib.dag.entryAfter [ "a" ] 1;
-}
-
would place b after a in the graph.
-
entryBefore
lib.dag.entryBefore (befores: list string) (value: T) : DagEntry<T>
Indicates that value must be placed before each of the attribute names in
-the given list. For example
foo.bar = {
- b = lib.dag.entryBefore [ "a" ] 1;
- a = 0;
-}
-
would place b before a in the graph.
-
entryBetween
lib.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T>
Indicates that value must be placed before the attribute names in the first
-list and after the attribute names in the second list. For example
foo.bar = {
- a = 0;
- c = lib.dag.entryBetween [ "b" ] [ "a" ] 2;
- b = 1;
-}
-
would place c before b and after a in the graph.
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 tag as argument and the DAG entries will be named
-${tag}-${index}.
lib.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
-The list of values are placed are placed after each of the attribute names in
-afters. For example
foo.bar =
- { b = 0; } // lib.dag.entriesAfter "a" [ "b" ] [ 1 2 ];
-
lib.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
-The list of values are placed before each of the attribute names in befores.
-For example
foo.bar =
- { b = 0; } // lib.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
-
lib.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T>
Creates a DAG with the given values with each entry labeled using the given tag.
-The list of values are placed before each of the attribute names in befores
-and after each of the attribute names in afters. For example
foo.bar =
- { b = 0; c = 3; } // lib.dag.entriesBetween "a" [ "b" ] [ "c" ] [ 1 2 ];
-
From the previous chapter, it should be clear that DAGs are useful, because you
-can add code that relies on other code. However, if you don’t know what the
-entries are called, it’s hard to do that, so here is a list of the internal
-entries in nvf:
vim.luaConfigRC (top-level DAG)
(luaConfigPre) - not a part of the actual DAG, instead, it’s simply
-inserted before the rest of the DAG
globalsScript - used to set globals defined in vim.globals
basic - used to set basic configuration options
optionsScript - used to set options defined in vim.o
theme (this is simply placed before pluginConfigs and lazyConfigs,
-meaning that surrounding entries don’t depend on it) - used to set up the
-theme, which has to be done before other plugins
lazyConfigs - lz.n and lzn-auto-require configs. If vim.lazy.enable
-is false, this will contain each plugin’s config instead.
pluginConfigs - the result of the nested vim.pluginRC (internal option,
-see the Custom Plugins page for adding your
-own plugins) DAG, used to set up internal plugins
extraPluginConfigs - the result of vim.extraPlugins, which is not a
-direct DAG, but is converted to, and resolved as one internally
We recognize that you might not always want to configure your setup purely in
-Nix, sometimes doing things in Lua is simply the “superior” option. In such a
-case you might want to configure your Neovim instance using Lua, and nothing but
-Lua. It is also possible to mix Lua and Nix configurations.
Pure Lua or hybrid Lua/Nix configurations can be achieved in two different ways.
-Purely, by modifying Neovim’s runtime directory or impurely by placing Lua
-configuration in a directory found in $HOME. For your convenience, this
-section will document both methods as they can be used.
Pure Runtime Directory
As of 0.6, nvf allows you to modify Neovim’s runtime path to suit your needs.
-One of the ways the new runtime option is to add a configuration located
-relative to your flake.nix, which must be version controlled in pure flakes
-manner.
{
- # Let us assume we are in the repository root, i.e., the same directory as the
- # flake.nix. For the sake of the argument, we will assume that the Neovim lua
- # configuration is in a nvim/ directory relative to flake.nix.
- vim = {
- additionalRuntimeDirectories = [
- # This will be added to Neovim's runtime paths. Conceptually, this behaves
- # very similarly to ~/.config/nvim but you may not place a top-level
- # init.lua to be able to require it directly.
- ./nvim
- ];
- };
-}
-
This will add the nvim directory, or rather, the store path that will be
-realised after your flake gets copied to the Nix store, to Neovim’s runtime
-directory. You may now create a lua/myconfig directory within this nvim
-directory, and call it with vim.luaConfigRC.
{pkgs, ...}: {
- vim = {
- additionalRuntimeDirectories = [
- # You can list more than one file here.
- ./nvim-custom-1
-
- # To make sure list items are ordered, use lib.mkBefore or lib.mkAfter
- # Simply placing list items in a given order will **not** ensure that
- # this list will be deterministic.
- ./nvim-custom-2
- ];
-
- startPlugins = [pkgs.vimPlugins.gitsigns];
-
- # Neovim supports in-line syntax highlighting for multi-line strings.
- # Simply place the filetype in a /* comment */ before the line.
- luaConfigRC.myconfig = /* lua */ ''
- -- Call the Lua module from ./nvim/lua/myconfig
- require("myconfig")
-
- -- Any additional Lua configuration that you might want *after* your own
- -- configuration. For example, a plugin setup call.
- require('gitsigns').setup({})
- '';
- };
-}
-
-
Impure Absolute Directory
As of Neovim 0.9, $NVIM_APPNAME is a variable expected by Neovim to
-decide on the configuration directory. nvf sets this variable as "nvf",
-meaning ~/.config/nvf will be regarded as the configuration directory by
-Neovim, similar to how ~/.config/nvim behaves in regular installations. This
-allows some degree of Lua configuration, backed by our low-level wrapper
-mnw. Creating a lua/ directory located in
-$NVIM_APPNAME (“nvf” by default) and placing your configuration in, e.g.,
-~/.config/nvf/lua/myconfig will allow you to require it as a part of the Lua
-module system through nvf’s module system.
Let’s assume your ~/.config/nvf/lua/myconfig/init.lua consists of the
-following:
The following Nix configuration via vim.luaConfigRC will allow loading
-this
{
- # The attribute name "myconfig-dir" here is arbitrary. It is required to be
- # a *named* attribute by the DAG system, but the name is entirely up to you.
- vim.luaConfigRC.myconfig-dir = ''
- require("myconfig")
-
- -- Any additional Lua
- '';
-}
-
After you load your custom configuration, you may use an init.lua located in
-your custom configuration directory to configure Neovim exactly as you would
-without a wrapper like nvf. If you want to place your require call in a
-specific position (i.e., before or after options you set in nvf) the
-DAG system will let you place your configuration in a location of your
-choosing.
There may be instances where the your Nix configuration evaluates to invalid
-Lua, or times when you will be asked to provide your built Lua configuration for
-easier debugging by nvf maintainers. nvf provides two helpful utilities out of
-the box.
nvf-print-config and nvf-print-config-path will be bundled with nvf as
-lightweight utilities to help you view or share your built configuration when
-necessary.
To view your configuration with syntax highlighting, you may use the
-bat pager.
nvf-print-config | bat --language=lua
-
Alternatively, cat or less may also be used.
Accessing neovimConfig
It is also possible to access the configuration for the wrapped package. The
-built Neovim package will contain a neovimConfig attribute in its
-passthru.
-
-
-
Offline Documentation
The manpages provided by nvf contains an offline version of the option search
-normally available at https://notashelf.github.io/nvf/options.html. You may
-use the man 5 nvf command to view option documentation from the comfort of
-your terminal.
Note that this is only available for NixOS and Home-Manager module
-installations.
nvf is designed for the developer as much as it is designed for the end-user. We
-would like for any contributor to be able to propagate their changes, or add new
-features to the project with minimum possible friction. As such, below are the
-guides and guidelines written to streamline the contribution process and to
-ensure that your valuable input integrates into nvf’s development as seamlessly
-as possible without leaving any question marks in your head.
This section is directed mainly towards those who wish to contribute code into
-the project. If you instead wish to report a bug, or discuss a potential new
-feature implementation (which you do not wish to implement yourself) first look
-among the already open issues and if no matching issue exists you may open a
-new issue 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. If you wish to make a contribution, but feel stuck -
-please do not be afraid to submit a pull request, we will help you get it in.
Getting Started
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 for
-instructions on how you can do this. Once you have a fork of nvf, you should
-create a separate branch based on the most 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 our
-Contributing Guidelines, push the branch to GitHub and
-create 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.
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 ideally (but not
-necessarily) before you start developing.
Adding Documentation
Almost all changes warrant updates to the documentation: at the very least, you
-must update the changelog. Both the manual and module options use
-Nixpkgs Flavoured Markdown.
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:
Make sure your code is formatted as described in
-code-style section. To maintain consistency
-throughout the project you are encouraged to browse through existing code and
-adopt its style also in new code.
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, 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
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 for a commit message
-that fulfills these requirements.
starship: allow running in Emacs if vterm is used
-
-The vterm buffer is backed by libvterm and can handle Starship prompts
-without issues.
-
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, adds appropriate formatters and Treesitter grammars
-
Long description can be omitted 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.
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
Treewide
Keep lines at a reasonable width, ideally 80 characters or less. This also
-applies to string literals and module descriptions and documentation.
-
Nix
nvf is formatted by the 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:
# parent modules should always be unfolded
-# which means module = { value = ... } instead of module.value = { ... }
-module = {
- value = mkEnableOption "some description" // { default = true; }; # merges can be done inline where possible
-
- # same as parent modules, unfold submodules
- subModule = {
- # this is an option that contains more than one nested value
- # Note: try to be careful about the ordering of `mkOption` arguments.
- # General rule of thumb is to order from least to most likely to change.
- # This is, for most cases, type < default < description.
- # Example, if present, would be between default and description
- someOtherValue = mkOption {
- type = lib.types.bool;
- default = true;
- description = "Some other description";
- };
- };
-}
-
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.
module = {
- key = mkEnableOption "some description" // {
- default = true; # we want this to be inline
- }; # ...
-}
-
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.
# this is ok
-acceptableList = [
- item1 # comment
- item2
- item3 # some other comment
- item4
-];
-
-# this is not ok
-listToBeAvoided = [item1 item2 /* comment */ item3 item4];
-
-# this is ok
-acceptableList = [item1 item2];
-
-# this is also ok if the list is expected to contain more elements
-acceptableList= [
- item1
- item2
- # more items if needed...
-];
-
-
-
-
-
-
Testing Changes
Once you have made your changes, you will need to test them thoroughly. 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 possible.
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.
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. The
-following section contains a general overview to how you may utilize said
-functions.
Custom Key Mappings Support for a Plugin
To set a mapping, you should define it in vim.keymaps.
An example, simple keybinding, can look like this:
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.
Below are the module options provided by nvf, in no particular order. Most
-options will include useful comments, warnings or setup tips on how a module
-option is meant to be used as well as examples in complex cases.
An offline version of this page is bundled with nvf as a part of the manpages
-which you can access with man 5 nvf. Please us know if you believe any of the
-options below are missing useful examples.
Additional arguments passed to each module in addition to ones
-like lib, config,
-and pkgs, modulesPath.
This option is also available to all submodules. Submodules do not
-inherit args from their parent module, nor do they provide args to
-their parent module or sibling submodules. The sole exception to
-this is the argument name which is provided by
-parent modules to a submodule and contains the attribute name
-the submodule is bound to, or a unique generated name if it is
-not bound to an attribute.
Some arguments are already passed by default, of which the
-following cannot be changed with this option:
lib: The nixpkgs library.
config: The results of all options after merging the values from all modules together.
options: The options declared in all modules.
specialArgs: The specialArgs argument passed to evalModules.
All attributes of specialArgs
Whereas option values can generally depend on other option values
-thanks to laziness, this does not apply to imports, which
-must be computed statically before anything else.
For this reason, callers of the module system can provide specialArgs
-which are available during import resolution.
For NixOS, specialArgs includes
-modulesPath, which allows you to import
-extra modules from the nixpkgs package tree without having to
-somehow make the module aware of the location of the
-nixpkgs or NixOS directories.
the experimental Lua module loader to speed up the start up process
If true, this will enable the experimental Lua module loader which:
overrides loadfile
adds the lua loader using the byte-compilation cache
adds the libs loader
removes the default Neovim loader
Note
The Lua module loader is disabled by default. Before setting this option, please
-take a look at the [official documentation]. This option may be enabled by
-default in the future.
Additional runtime paths that will be appended to the
-active runtimepath of the Neovim. This can be used to
-add additional lookup paths for configs, plugins, spell
-languages and other things you would generally place in
-your $HOME/.config/nvim.
This is meant as a declarative alternative to throwing
-files into ~/.config/nvim and having the Neovim
-wrapper pick them up. For more details on
-vim.o.runtimepath, and what paths to use; please see
-the official documentation
-
-
Type:
-list of (absolute path or string)
-
-
Default:
-[ ]
-
-
Example:
[
- # absolute path, as a string - impure
- "$HOME/.config/nvim-extra"
-
- # relative path, as a path - pure
- ./nvim
-
- # source type path - pure and reproducible
- (builtins.source {
- path = ./runtime;
- name = "nvim-runtime";
- })
-]
-
-
A list of Neovim autogroups, which are used to organize and manage related
-autocommands together. Groups allow multiple autocommands to be cleared
-or redefined collectively, preventing duplicate definitions.
Each autogroup consists of a name, a boolean indicating whether to clear
-existing autocommands, and a list of associated autocommands.
The comparator functions used for sorting completions.
You can either pass a valid inline lua function
-(see :help cmp-config.sorting.comparators),
-or a string, in which case the builtin comparator with that name will
-be used.
A deprio function and a kinds
-(require("cmp.types").lsp.CompletionItemKind) variable is provided
-above setupOpts. By passing a type to the function, the returned
-function will be a comparator that always ranks the specified kind the
-lowest.
Map of filetype to formatters. This option takes a set of
-key = value format where the value will be converted
-to its Lua equivalent. You are responsible for passing the
-correct Nix data types to generate a correct Lua value that
-conform is able to accept.
Additional lua files that will be sourced by Neovim.
-Takes both absolute and relative paths, all of which
-will be called via the luafile command in Neovim.
See lua-commands
-on the Neovim documentation for more details.
Warning
All paths passed to this option must be valid. If Neovim cannot
-resolve the path you are attempting to source, then your configuration
-will error, and Neovim will not start. Please ensure that all paths
-are correct before using this option.
-
-
Type:
-list of (absolute path or string)
-
-
Default:
-[ ]
-
-
Example:
[
- # absolute path, as a string - impure
- "$HOME/.config/nvim/my-lua-file.lua"
-
- # relative path, as a path - pure
- ./nvim/my-lua-file.lua
-
- # source type path - pure and reproducible
- (builtins.path {
- path = ./nvim/my-lua-file.lua;
- name = "my-lua-file";
- })
-]
-
-
Change the default window picker, can be a string "default" or a function.
-The function should return the window id that will open the node,
-or nil if an invalid window is picked or user cancelled the action.
The picker may create a new window.
-
-
Type:
-string
-
-
Default:
-"default"
-
-
Example:
-- with s1n7ax/nvim-window-picker plugin
-require('window-picker').pick_window,
-
-
A boolean value that toggle the use of system clipboard when copy/paste
-function are invoked. When enabled, copied text will be stored in registers
-‘+’ (system), otherwise, it will be stored in ‘1’ and ‘"’.
Will use file system watcher (libuv fs_event) to watch the filesystem for changes.
-Using this will disable BufEnter / BufWritePost events in nvim-tree which
-were used to update the whole tree. With this feature, the tree will be
-updated only for the appropriate folder change, resulting in better
-performance.
List of vim regex for absolute directory paths that will not be watched.
-Backslashes must be escaped e.g. "my-project/\\.build$".
-Useful when path is not in .gitignore or git integration is disabled.
Enable the hijack_directories feature. Disable this option if you use vim-dirvish or dirbuf.nvim.
-If hijack_netrw and disable_netrw are false, this feature will be disabled.
Configurations for the live_filtering feature.
-The live filter allows you to filter the tree nodes dynamically, based on
-regex matching (see vim.regex).
-This feature is bound to the f key by default.
-The filter can be cleared with the F key by default.
Enable file highlight for git attributes using NvimTreeGit highlight groups.
-Requires nvimTree.git.enable
-This can be used with or without the icons.
In what format to show root folder. See :help filename-modifiers for
-available string options.
-Set to false to hide the root folder.
Function is passed the absolute path of the root folder and should
-return a string. e.g.
-my_root_folder_label = function(path)
-return “…/” … vim.fn.fnamemodify(path, “:t”)
-end
List of buffer names and filetypes that will not update the root dir
-of the tree if the file isn’t found under the current root directory.
-Only relevant when update_focused_file.update_root and
-update_focused_file.enable are true.
Update the root directory of the tree if the file is not under current
-root directory. It prefers vim’s cwd and root_dirs.
-Otherwise it falls back to the folder containing the file.
-Only relevant when update_focused_file.enable is true
Show the line number relative to the line with the cursor in front of each line.
-If the option view.number is also true, the number on the cursor line
-will be the line number instead of 0.
Map of filetype to formatters. This option takes a set of
-key = value format where the value will be converted
-to its Lua equivalent. You are responsible for passing the
-correct Nix data types to generate a correct Lua value that
-conform is able to accept.
A freeform attribute set containing global variable values for setting vim
-variables as early as possible. If populated, this option will set vim variables
-in the built luaConfigRC as the first item.
Note
{foo = "bar";} will set vim.g.foo to “bar”, where the type of bar in the
-resulting Lua value will be inferred from the type of the value in the
-{name = value;} pair passed to the option.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to patch flutter-tools so that it doesn’t resolve
-symlinks when detecting flutter path.
This is required if you want to use a flutter package built with nix.
-If you are using a flutter SDK installed from a different source
-and encounter the error “dart missing from PATH”, disable this option.
The entirety of Julia is bundled with nvf, if you enable this
-option, since there is no way to provide only the LSP server.
If you want to avoid that, you have to change
-vim.languages.julia.lsp.package to use the Julia binary
-in PATH (set it to null), and add the LanguageServer package to
-Julia in your devshells.
Remove the ‘F’ flag from shortmess to allow messages to be shown. Without doing this, autocommands that deal with filetypes prohibit messages from being shown
if set to true, the filetype of the otterbuffers will be set. Other wide only
-the autocommand of lspconfig that attaches the language server will be
-executed without setting the filetype
write <path>.otter.<embedded language extension> files to disk on save of main buffer.
-Useful for some linters that require actual files.
-Otter files are deleted on quit or main buffer close
:h events that cause the diagnostic to update.
-Set to: {“BufWritePost”, “InsertLeave”, “TextChanged” }
-for less performant but more instant diagnostic updates
Verbatim lua code that will be inserted before
-the result of luaConfigRc DAG has been resolved.
This option does not take a DAG set, but a string
-instead. Useful when you’d like to insert contents
-of lua configs after the DAG result.
Warning
You do not want to override this option with mkForce
-It is used internally to set certain options as early
-as possible and should be avoided unless you know what
-you’re doing. Passing a string to this option will
-merge it with the default contents.
-
-
Type:
-string
-
-
Default:
-By default, this option will append paths in
-vim.additionalRuntimePaths
-to the runtimepath and enable the experimental Lua module loader
-if vim.enableLuaLoader is set to true.
If this option is passed as a DAG, it will be resolved
-according to the DAG resolution rules (e.g. entryBefore
-or entryAfter) as per the nvf extended library.
-
-
Type:
-(DAG of strings concatenated with “\n”) or string
-
-
Default:
-{ }
-
-
Example:
-- Set the tab size to 4 spaces
-vim.opt.tabstop = 4
-vim.opt.shiftwidth = 4
-vim.opt.expandtab = true
-
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
Whether to use the ‘noremap’ variant of the command, ignoring any custom mappings on the defined action. It is highly advised to keep this on, which is the default.
This option has the same type definition as vim.startPlugins
-and plugins in this list are appended to vim.startPlugins by
-the wrapper during the build process.
To avoid overriding packages and dependencies provided by startPlugins, you
-are recommended to use this option or vim.extraPlugins option.
A freeform attribute set containing vim options to be set as early as possible.
-If populated, this option will set vim options in the built luaConfigRC
-after basic and before pluginConfigs DAG entries.
Note
{foo = "bar";} will set vim.o.foo to “bar”, where the type of bar in the
-resulting Lua value will be inferred from the type of the value in the
-{name = value;} pair passed to the option.
This option takes a string to ensure proper conversion to the corresponding Lua type.
-As such, we do not check the value passed to this option. Please ensure that any value
-that is set here is a valid value as per neovim documentation.
Define what to do when Neovim is started without arguments.
Takes either one of "Disabled", "CurrentDir", "LastSession in which case the value
-will be inserted into sm.AutoloadMode.<value>, or an inline Lua value.
-
-
Type:
-one of “Disabled”, “CurrentDir”, “LastSession” or (luaInline)
Additional words to be used for spellchecking. The names of each key will be
-used as the language code for the spell file. For example
"en.utf-8" = [ ... ];
-
will result in en.utf-8.add.spl being added to Neovim’s runtime in the
-spell directory.
Warning
The attribute keys must be in "<name>.<encoding>" format for Neovim to
-compile your spellfiles without mangling the resulting file names. Please
-make sure that you enter the correct value, as nvf does not do any kind of
-internal checking. Please see :help mkspell for more details.
Example:
# "en" is the name, and "utf-8" is the encoding. For most use cases, utf-8
-# will be enough, however, you may change it to any encoding format Neovim
-# accepts, e.g., utf-16.
-"en.utf-8" = ["nvf" "word_you_want_to_add"];
-=> $out/spell/en-utf-8.add.spl
-
Note that while adding a new language, you will still need to add the name of
-the language (e.g. “en”) to the vim.spellcheck.languages list by name
-in order to enable spellchecking for the language. By default only "en" is in
-the list.
A list of languages that should be used for spellchecking.
To add your own language files, you may place your spell directory in either
-$XDG_CONFIG_HOME/nvf or in a path that is included in the
-additionalRuntimePaths list provided by nvf.
[
- ''
- {
- -- Lsp server name
- function()
- local buf_ft = vim.api.nvim_get_option_value('filetype', {})
-
- -- List of buffer types to exclude
- local excluded_buf_ft = {"toggleterm", "NvimTree", "neo-tree", "TelescopePrompt"}
-
- -- Check if the current buffer type is in the excluded list
- for _, excluded_type in ipairs(excluded_buf_ft) do
- if buf_ft == excluded_type then
- return ""
- end
- end
-
- -- Get the name of the LSP server active in the current buffer
- local clients = vim.lsp.get_active_clients()
- local msg = 'No Active Lsp'
-
- -- if no lsp client is attached then return the msg
- if next(clients) == nil then
- return msg
- end
-
- for _, client in ipairs(clients) do
- local filetypes = client.config.filetypes
- if filetypes and vim.fn.index(filetypes, buf_ft) ~= -1 then
- return client.name
- end
- end
-
- return msg
- end,
- icon = ' ',
- separator = {left = ''},
- }
- ''
- ''
- {
- "diagnostics",
- sources = {'nvim_lsp', 'nvim_diagnostic', 'nvim_diagnostic', 'vim_lsp', 'coc'},
- symbols = {error = ' ', warn = ' ', info = ' ', hint = ' '},
- colored = true,
- update_in_insert = false,
- always_visible = false,
- diagnostics_color = {
- color_error = { fg = 'red' },
- color_warn = { fg = 'yellow' },
- color_info = { fg = 'cyan' },
- },
- }
- ''
-]
-
This will be called a lot, so you are encouraged to keep it as
-short and lightweight as possible unless you are fully aware
-of the performance implications.
-
-
Type:
-null or (luaInline)
-
-
Default:
-null
-
-
Example:
custom_filter = function(buf_number, buf_numbers)
- -- filter out filetypes you don't want to see
- if vim.bo[buf_number].filetype ~= "<i-dont-want-to-see-this>" then
- return true
- end
- -- filter out by buffer name
- if vim.fn.bufname(buf_number) ~= "<buffer-name-I-dont-want>" then
- return true
- end
- -- filter out based on arbitrary rules
- -- e.g. filter out vim wiki buffer from tabline in your work repo
- if vim.fn.getcwd() == "<work-repo>" and vim.bo[buf_number].filetype ~= "wiki" then
- return true
- end
- -- filter out by it's index number in list (don't show first buffer)
- if buf_numbers[1] ~= buf_number then
- return true
- end
-end
-
-
Function to get the diagnostics indicator.
-The function should return a string to be used as the indicator.
Can be set to nil to keep the buffer name highlight, but delete the
-highlighting.
-
-
Type:
-null or (luaInline)
-
-
Default:
{
- _type = "lua-inline";
- expr = ''
- function(count, level, diagnostics_dict, context)
- local s = " "
- for e, n in pairs(diagnostics_dict) do
- local sym = e == "error" and " "
- or (e == "warning" and " " or " " )
- s = s .. n .. sym
- end
- return s
- end
- '';
-}
-
Whether to update diagnostics while in insert mode.
Setting this to true has performance implications, but they may be
-negligible depending on your setup. Set it to true if you know what
-you are doing.
Defines the command that will be used for live_grep and grep_string pickers.
-Make sure that color is set to never because telescope does not yet interpret color codes.
Supported themes can be found in supportedThemes.nix.
-Setting the theme to “base16” enables base16 theming and
-requires all of the colors in vim.theme.base16-colors to be set.
For languages already supported by nvf, you may
-use the vim.language.<lang>.treesitter options, which
-will automatically add the required grammars to this.
Setting this to true will run :h syntax and tree-sitter at the same time.
-You may this to true if you depend on ‘syntax’ being enabled (like for
-indentation).
Note
Using this option may slow down your editor, and you may see some duplicate
-highlights.
List of treesitter grammars to disable highlighting for.
This option can be either a list, in which case it will be
-converted to a Lua table containing grammars to disable
-highlighting for, or a string containing a lua function
-that will be read as is.
Warning
A comma will be added at the end of your function, so you
-do not need to add it yourself. Doing so will cause in
-syntax errors within your Neovim configuration.
-
-
Type:
-(list of string) or (luaInline)
-
-
Default:
-[ ]
-
-
Example:
-- Disable slow treesitter highlight for large files
-function(lang, buf)
- local max_filesize = 1000 * 1024 -- 1MB
- local ok, stats = pcall(vim.loop.fs_stat, vim.api.nvim_buf_get_name(buf))
- if ok and stats and stats.size > max_filesize then
- return true
- end
-end
-
List of treesitter grammars to disable incremental selection
-for.
This option can be either a list, in which case it will be
-converted to a Lua table containing grammars to disable
-indentation for, or a string containing a lua function
-that will be read as is.
Warning
A comma will be added at the end of your function, so you
-do not need to add it yourself. Doing so will cause in
-syntax errors within your Neovim configuration.
List of treesitter grammars to disable indentation for.
This option can be either a list, in which case it will be
-converted to a Lua table containing grammars to disable
-indentation for, or a string containing a lua function
-that will be read as is.
Warning
A comma will be added at the end of your function, so you
-do not need to add it yourself. Doing so will cause in
-syntax errors within your Neovim configuration.
If a list is given, it should have a length of eight or any divisor of
-eight. The array will specify the eight chars building up the border in
-a clockwise fashion starting with the top-left corner. You can specify
-a different highlight group for each character by passing a
-[char, “YourHighlightGroup”] instead
-
-
Type:
-one of “none”, “single”, “double”, “rounded”, “solid”, “shadow” or list of (string or list of string)
nvim-surround: add/change/delete surrounding delimiter pairs with ease.
-Note that the default mappings deviate from upstream to avoid conflicts
-with nvim-leap.
Configuration used to generate an animation to be registered.
The final value for ca_config will be used to register a new
-animation using require("cellular-automaton").register_animation(ca_config)
Warning
ca_configmust eval to a valid Lua table. nvf does not and cannot
-perform any kind of validation on your Lua code, so bogus values will
-result in errors when the animation is registered.
-
-
Type:
-luaInline
-
-
Default:
{
- _type = "lua-inline";
- expr = ''
- local ca_config = {
- fps = 50,
- name = 'slide',
- }
-
- -- init function is invoked only once at the start
- -- config.init = function (grid)
- --
- -- end
-
- -- update function
- ca_config.update = function (grid)
- for i = 1, #grid do
- local prev = grid[i][#(grid[i])]
- for j = 1, #(grid[i]) do
- grid[i][j], prev = prev, grid[i][j]
- end
- end
- return true
- end
- '';
-}
-
The min_length option defines the minimum number of characters
-a word must have to be highlighted as a “cursor word.” Any word
-shorter than this value will be ignored and not highlighted.
At times, certain plugins and modules may refuse to play nicely with your setup,
-be it a result of generating Lua from Nix, or the state of packaging. This page,
-in turn, will list any known modules or plugins that are known to misbehave, and
-possible workarounds that you may apply.
When working with NodeJS, everything works as expected, but some projects have
-settings that can fool nvf.
If this plugin or similar
-is included, you might get a situation where your eslint configuration diagnoses
-your formatting according to its own config (usually .eslintrc.js).
The issue there is your formatting is made via prettierd.
This results in auto-formatting relying on your prettier config, while your
-eslint config diagnoses formatting
-which it’s not supposed to)
In the end, you get discrepancies between what your editor does and what it
-wants.
Solutions are:
Don’t add a formatting config to eslint, and separate prettier and eslint.
PR this repo to add an ESLint formatter and configure nvf to use it.
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs-preview-707/release-notes.html b/docs-preview-707/release-notes.html
deleted file mode 100644
index b38f9392..00000000
--- a/docs-preview-707/release-notes.html
+++ /dev/null
@@ -1,383 +0,0 @@
-
-
-
-
-
- Appendix C. Release Notes
-
-
-
-
-
-
-
-
Removed hare language support (lsp/tree-sitter/etc). vim.lsp.hare is no
-longer defined. If you use hare and would like it added back, please file an
-issue.
vim.startPlugins & vim.optPlugins are now an enum of
-string for options sourced from the flake inputs. Users can still provide
-vim plugin packages.
If you are contributing and adding a new plugin, add the plugin name to
-availablePlugins in [types-plugin.nix].
neovimBuilder has been removed for configuration. Using an overlay is no
-longer required. See the manual for the new way to configuration.
Treesitter grammars are now configurable with
-vim.treesitter.grammars. Utilizes the nixpkgs nvim-treesitter
-plugin rather than a custom input in order to take advantage of build support
-of pinned versions. See the relevant discourse post for more information.
-Packages can be found under the vimPlugins.nvim-treesitter.builtGrammars
-namespace.
vim.configRC and vim.luaConfigRC are now of type DAG lines. This
-allows for ordering of the config. Usage is the same is in home-manager’s
-home.activation option.
Added two minimap plugins under vim.minimap. codewindow.nvim is enabled by
-default, while minimap.vim is available with its code-minimap dependency.
A complementary plugin, obsidian.nvim and the Neovim alternative for Emacs’
-orgmode with orgmode.nvim have been added. Both will be disabled by default.
Smooth scrolling for ANY movement command is now available with
-cinnamon.nvim
You will now notice a dashboard on startup. This is provided by the
-alpha.nvim plugin. You can use any of the three available dashboard plugins,
-or disable them entirely.
There is now a scrollbar on active buffers, which can highlight errors by
-hooking to your LSPs. This is on by default, but can be toggled off under
-vim.visuals if seen necessary.
Discord Rich Presence has been added through presence.nvim for those who
-want to flex that they are using the superior text editor.
An icon picker is now available with telescope integration. You can use
-:IconPickerInsert or :IconPickerYank to add icons to your code.
A general-purpose cheatsheet has been added through cheatsheet.nvim. Forget
-no longer!
ccc.nvim has been added to the default plugins to allow picking colors with
-ease.
Most UI components of Neovim have been replaced through the help of
-noice.nvim. There are also notifications and custom UI elements available
-for Neovim messages and prompts.
A (floating by default) terminal has been added through toggleterm.nvim.
Harness the power of ethical (tabnine.nvim) and not-so-ethical
-(copilot.lua) AI by those new assistant plugins. Both are off by default,
-TabNine needs to be wrapped before it’s working.
Experimental mouse gestures have been added through gesture.nvim. See plugin
-page and the relevant module for more details on how to use.
Re-open last visited buffers via nvim-session-manager. Disabled by default
-as deleting buffers seems to be problematic at the moment.
Most of NvimTree’s configuration options have been changed with some options
-being toggled to off by default.
Lualine had its configuration simplified and style toned down. Less color,
-more info.
Modules where multiple plugin configurations were in the same directory have
-been simplified. Each plugin inside a single module gets its directory to be
-imported.
Separate config options with the same parent attribute have been merged into
-one for simplicity.
Release 0.3 had to come out before I wanted it to due to Neovim 0.9 dropping
-into nixpkgs-unstable. The Treesitter changes have prompted a Treesitter rework,
-which was followed by reworking the languages system. Most of the changes to
-those are downstreamed from the original repository. The feature requests that
-was originally planned for 0.3 have been moved to 0.4, which should come out
-soon.
Changelog
We have transitioned to flake-parts, from flake-utils to extend the
-flexibility of this flake. This means the flake structure is different than
-usual, but the functionality remains the same.
We now provide a home-manager module. Do note that it is still far from
-perfect, but it works.
nodejs_16 is now bundled with Copilot.lua if the user has enabled Copilot
-assistant.
which-key section titles have been fixed. This is to be changed once again in
-a possible keybind rewrite, but now it should display the correct titles
-instead of +prefix
Most of presence.nvim’s options have been made fully configurable through
-your configuration file.
Most of the modules have been refactored to separate config and options
-attributes.
Darwin has been deprecated as the Zig package is marked as broken. We will
-attempt to use the Zig overlay to return Darwin support.
Fidget.nvim has been added as a neat visual addition for LSP installations.
diffview.nvim has been added to provide a convenient diff utility.
Treesitter grammars are now configurable with
-vim.treesitter.grammars. Utilizes the nixpkgs nvim-treesitter
-plugin rather than a custom input in order to take advantage of build support
-of pinned versions. See discourse for more information. Packages can be
-found under the pkgs.vimPlugins.nvim-treesitter.builtGrammars attribute.
-Treesitter grammars for supported languages should be enabled within the
-module. By default no grammars are installed, thus the following grammars
-which do not have a language section are not included anymore: comment,
-toml, make, html, css, graphql, json.
A new section has been added for language support: vim.languages.<language>.
Improved handling of completion formatting. When setting
-vim.autocomplete.sources, can also include optional menu mapping. And can
-provide your own function with vim.autocomplete.formatting.format.
For vim.visuals.indentBlankline.fillChar and
-vim.visuals.indentBlankline.eolChar options, turning them off should be done
-by using null rather than "" now.
Transparency has been made optional and has been disabled by default.
-vim.theme.transparent option can be used to enable or disable
-transparency for your configuration.
Fixed deprecated configuration method for Tokyonight, and added new style
-“moon”
Dart language support as well as extended flutter support has been added.
-Thanks to @FlafyDev for his contributions towards Dart language support.
Elixir language support has been added through elixir-tools.nvim.
hop.nvim and leap.nvim have been added for fast navigation.
modes.nvim has been added to the UI plugins as a minor error highlighter.
smartcollumn.nvim has been added to dynamically display a colorcolumn when
-the limit has been exceeded, providing per-buftype column position and more.
project.nvim has been added for better project management inside Neovim.
More configuration options have been added to nvim-session-manager.
Editorconfig support has been added to the core functionality, with an enable
-option.
venn-nvim has been dropped due to broken keybinds.
Following the release of v0.3, I have decided to release v0.4 with a massive new
-change: customizable keybinds. As of the 0.4 release, keybinds will no longer be
-hardcoded and instead provided by each module’s own keybinds section. The old
-keybind system (vim.keybinds = {}) is now considered deprecated and the new
-lib functions are recommended to be used for adding keybinds for new plugins, or
-adding keybinds to existing plugins.
Alongside customizable keybinds, there are a few quality of life updates, such
-as lazygit integration and the new experimental Lua loader of Neovim 0.9
-thanks to our awesome contributors who made this update possible during my
-absence.
Added lsp_lines plugin for showing diagnostic messages
Added a configuration option for choosing the leader key
The package used for neovim is now customizable by the user, using
-vim.package. For best results, always use an unwrapped package
Added highlight-undo plugin for highlighting undo/redo targets
Added bash LSP and formatter support
Disabled Lualine LSP status indicator for Toggleterm buffer
Added nvim-docs-view, a plugin to display LSP hover documentation in a side
-panel
Switched to nixosOptionsDoc in option documentation. To quote home-manager
-commit: “Output is mostly unchanged aside from some minor typographical and
-formatting changes, along with better source links.”
Updated indent-blankine.nvim to v3 - this comes with a few option changes,
-which will be migrated with renamedOptionModule
In v0.6 we are introducing setupOpts: many plugin related options are moved
-into their respective setupOpts submodule, e.g. nvimTree.disableNetrw is
-renamed to nvimTree.setupOpts.disable_netrw.
Why? in short, you can now pass in anything to setupOpts and it will be passed
-to your require'plugin'.setup{...}. No need to wait for us to support every
-single plugin option.
The warnings when you rebuild your config should be enough to guide you through
-what you need to do, if there’s an option that was renamed but wasn’t listed in
-the warning, please file a bug report!
To make your migration process less annoying, here’s a keybind that will help
-you with renaming stuff from camelCase to snake_case (you’ll be doing that a
-lot):
-- paste this in a temp.lua file and load it in vim with :source /path/to/temp.lua
-function camelToSnake()
- -- Get the current word under the cursor
- local word = vim.fn.expand("<cword>")
- -- Replace each capital letter with an underscore followed by its lowercase equivalent
- local snakeCase = string.gsub(word, "%u", function(match)
- return "_" .. string.lower(match)
- end)
- -- Remove the leading underscore if present
- if string.sub(snakeCase, 1, 1) == "_" then
- snakeCase = string.sub(snakeCase, 2)
- end
- vim.fn.setreg(vim.v.register, snakeCase)
- -- Select the word under the cursor and paste
- vim.cmd("normal! viwP")
-end
-
-vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap = true, silent = true })
-
Added ChatGPT.nvim, which can be enabled with
-vim.assistant.chatgpt.enable. Do keep in mind that this option
-requires OPENAI_API_KEY environment variable to be set.
Added option vim.luaPackages to wrap neovim with extra Lua packages.
Rewrote the entire fidget.nvim module to include extensive configuration
-options. Option vim.fidget-nvim.align.bottom has been removed in favor of
-vim.fidget-nvim.notification.window.align, which now supports top and
-bottom values. vim.fidget-nvim.align.right has no longer any equivalent
-and also has been removed.
Finished moving to nixosOptionsDoc in the documentation and changelog. All
-documentation options and files are fully free of Asciidoc, and will now use
-Nixpkgs flavored markdown.
Bumped plugin inputs to their latest versions.
Deprecated presence.nvim in favor of neocord. This means
-vim.rich-presence.presence-nvim is removed and will throw a warning if used.
-You are recommended to rewrite your neocord configuration from scratch based
-on the. official documentation
Removed Tabnine plugin due to the usage of imperative tarball downloads. If
-you’d like to see it back, please create an issue.
Added support for css and tailwindcss through
-vscode-language-servers-extracted & tailwind-language-server. Those can be
-enabled through vim.languages.css and vim.languages.tailwind.
Updated all plugin inputs to their latest versions (21.04.2024) - this
-brought minor color changes to the Catppuccin theme.
Moved home-manager module entrypoint to flake/modules and added an
-experimental Nixos module. This requires further testing before it can be
-considered ready for use.
Made lib calls explicit. E.g. lib.strings.optionalString instead of
-lib.optionalString. This is a pattern expected to be followed by all
-contributors in the future.
Added image.nvim for image previews.
The final neovim package is now exposed. This means you can build the neovim
-package that will be added to your package list without rebuilding your system
-to test if your configuration yields a broken package.
Changed the tree structure to distinguish between core options and plugin
-options.
Added plugin auto-discovery from plugin inputs. This is mostly from
-JordanIsaac’s neovim-flake.
-Allows contributors to add plugin inputs with the plugin- prefix to have
-them automatically discovered for the plugin type in lib/types.
Moved internal wrapLuaConfig to the extended library, structured its
-arguments to take luaBefore, luaConfig and luaAfter as strings, which
-are then concatted inside a lua block.
Added vim.luaConfigPre and vim.luaConfigPost for inserting
-verbatim Lua configuration before and after the resolved Lua DAG respectively.
-Both of those options take strings as the type, so you may read the contents
-of a Lua file from a given path.
Added vim.spellchecking.ignoredFiletypes and
-vim.spellChecking.programmingWordlist.enable for ignoring certain filetypes
-in spellchecking and enabling vim-dirtytalk respectively. The previously
-used vim.spellcheck.vim-dirtytalk aliases to the latter option.
Exposed withRuby, withNodeJs, withPython3, and python3Packages from
-the makeNeovimConfig function under their respective options.
Added vim.extraPackages for appending additional packages to the
-wrapper PATH, making said packages available while inside the Neovim session.
Made Treesitter options configurable, and moved treesitter-context to
-setupOpts while it is enabled.
Added vim.notify.nvim-notify.setupOpts.render which takes either a
-string of enum, or a Lua function. The default is “compact”, but you may
-change it according to nvim-notify documentation.
In v0.7 we are removing vim.configRC in favor of making vim.luaConfigRC the
-top-level DAG, and thereby making the entire configuration Lua based. This
-change introduces a few breaking changes:
vim.configRC has been removed, which means that you have to convert all of
-your custom vimscript-based configuration to Lua. As for how to do that, you
-will have to consult the Neovim documentation and your search engine.
After migrating your Vimscript-based configuration to Lua, you might not be
-able to use the same entry names in vim.luaConfigRC, because those have also
-slightly changed. See the new DAG entries in nvf manual for more details.
Why?
Neovim being an aggressive refactor of Vim, is designed to be mainly Lua based;
-making good use of its extensive Lua API. Additionally, Vimscript is slow and
-brings unnecessary performance overhead while working with different
-configuration formats.
-
vim.maps rewrite
Instead of specifying map modes using submodules (e.g., vim.maps.normal), a
-new vim.keymaps submodule with support for a mode option has been
-introduced. It can be either a string, or a list of strings, where a string
-represents the short-name of the map mode(s), that the mapping should be set
-for. See :help map-modes for more information.
vim.lsp.nvimCodeActionMenu removed in favor of vim.ui.fastaction
The nvim-code-action-menu plugin has been archived and broken for a long time,
-so it’s being replaced with a young, but better alternative called
-fastaction.nvim. Simply remove everything set under
-vim.lsp.nvimCodeActionMenu, and set vim.ui.fastaction.enable to true.
Note that we are looking to add more alternatives in the future like
-dressing.nvim and actions-preview.nvim, in case fastaction doesn’t work for
-everyone.
-
type based modules removed
As part of the autocompletion rewrite, modules that used to use a type option
-have been replaced by per-plugin modules instead. Since both modules only had
-one type, you can simply change
nixpkgs-fmt has been archived for a while, and it’s finally being removed in
-favor of nixfmt (more information can be found
-here.
To migrate to nixfmt, simply change vim.languages.nix.format.type to
-nixfmt.
-
leader changes
This has been deprecated in favor of using the more generic vim.globals (you
-can use vim.globals.mapleader to change this instead).
Rust specific keymaps now use maplocalleader instead of localleader by
-default. This is to avoid conflicts with other modules. You can change
-maplocalleader with vim.globals.maplocalleader, but it’s recommended to set
-it to something other than mapleader to avoid conflicts.
-
vim.* changes
Inline with the leader changes, we have removed some
-options that were under vim as convenient shorthands for vim.o.* options.
Warning
As v0.7 features the addition of vim.options, those options are now
-considered as deprecated. You should migrate to the appropriate options in the
-vim.options submodule.
The changes are, in no particular order:
colourTerm, mouseSupport, cmdHeight, updateTime, mapTime,
-cursorlineOpt, splitBelow, splitRight, autoIndent and wordWrap have
-been mapped to their vim.options equivalents. Please see the module
-definition for the updated options.
tabWidth has been removed as it lead to confusing behaviour. You can
-replicate the same functionality by setting shiftwidth, tabstop and
-softtabstop under vim.options as you see fit.
Fix null vim.lsp.mappings generating an error and not being filtered out.
Add basic transparency support for oxocarbon theme by setting the highlight
-group for Normal, NormalFloat, LineNr, SignColumn and optionally
-NvimTreeNormal to none.
Fix broken treesitter-context keybinds in visual mode
Deprecate use of __empty to define empty tables in Lua. Empty attrset are no
-longer filtered and thus should be used instead.
Add dap-go for better dap configurations
Make noice.nvim customizable
Standardize border style options and add custom borders
Remove vim.disableDefaultRuntimePaths in wrapper options.
As nvf uses $NVIM_APP_NAME as of recent changes, we can safely assume any
-configuration in $XDG_CONFIG_HOME/nvf is intentional.
Switch from rust-tools.nvim to the more feature-packed rustaceanvim. This
-switch entails a whole bunch of new features and options, so you are
-recommended to go through rustacean.nvim’s README to take a closer look at its
-features and usage
Add lz.n support and lazy-load some builtin plugins.
Enabled the terminal integration of catppuccin for theming Neovim’s built-in
-terminal (this also affects toggleterm).
Migrate bufferline to setupOpts for more customizability
Use clangd as the default language server for C languages
Expose lib.nvim.types.pluginType, which for example allows the user to
-create abstractions for adding plugins
Migrate indent-blankline to setupOpts for more customizability. While the
-plugin’s options can now be found under indentBlankline.setupOpts, the
-previous iteration of the module also included out of place/broken options,
-which have been removed for the time being. These are:
listChar - this was already unused
fillChar - this had nothing to do with the plugin, please configure it
-yourself by adding vim.opt.listchars:append({ space = '<char>' }) to your
-lua configuration
eolChar - this also had nothing to do with the plugin, please configure it
-yourself by adding vim.opt.listchars:append({ eol = '<char>' }) to your
-lua configuration
Replace vim.lsp.nvimCodeActionMenu with vim.ui.fastaction, see the
-breaking changes section above for more details
Add a setupOpts option to nvim-surround, which allows modifying options that
-aren’t defined in nvf. Move the alternate nvim-surround keybinds to use
-setupOpts.
Remove autopairs.type, and rename autopairs.enable to
-autopairs.nvim-autopairs.enable. The new
-vim.autopairs.nvim-autopairs.enable supports setupOpts format by
-default.
Refactor of nvim-cmp and completion related modules
Deprecate legacy Vimsnip in favor of Luasnip, and integrate
-friendly-snippets for bundled snippets. vim.snippets.luasnip.enable
-can be used to toggle Luasnip.
Add C# support under vim.languages.csharp, with support for both
-omnisharp-roslyn and csharp-language-server.
Add Julia support under vim.languages.julia. Note that the entirety of Julia
-is bundled with nvf, if you enable the module, since there is no way to
-provide only the LSP server.
Add run.nvim support for running code
-using cached commands.
Make Neovim’s configuration file entirely Lua based. This comes with a few
-breaking changes:
vim.configRC has been removed. You will need to migrate your entries to
-Neovim-compliant Lua code, and add them to vim.luaConfigRC instead.
-Existing vimscript configurations may be preserved in vim.cmd functions.
-Please see Neovim documentation on vim.cmd
vim.luaScriptRC is now the top-level DAG, and the internal vim.pluginRC
-has been introduced for setting up internal plugins. See the “DAG entries in
-nvf” manual page for more information.
Rewrite vim.maps, see the breaking changes section above.
Add deno fmt as the default Markdown formatter. This will be enabled
-automatically if you have autoformatting enabled, but can be disabled manually
-if you choose to.
Add vim.extraLuaFiles for optionally sourcing additional lua files in your
-configuration.
Refactor programs.languages.elixir to use lspconfig and none-ls for LSP and
-formatter setups respectively. Diagnostics support is considered, and may be
-added once the credo linter has been added to nixpkgs. A pull request is
-currently open.
Remove vim-tidal and friends.
Clean up Lualine module to reduce theme dependency on Catppuccin, and fixed
-blending issues in component separators.
Add [ts-ereror-translator.nvim] extension of the TS language module, under
-vim.languages.ts.extensions.ts-error-translator to aid with Typescript
-development.
Add neo-tree.nvim as an alternative file-tree plugin. It will be available
-under vim.filetree.neo-tree, similar to nvimtree.
Add nvf-print-config & nvf-print-config-path helper scripts to Neovim
-closure. Both of those scripts have been automatically added to your PATH upon
-using neovimConfig or programs.nvf.enable.
nvf-print-config will display your init.lua, in full.
nvf-print-config-path will display the path to a clone of your
-init.lua. This is not the path used by the Neovim wrapper, but an
-identical clone.
Add vim.ui.breadcrumbs.lualine to allow fine-tuning breadcrumbs behaviour on
-Lualine. Only vim.ui.breadcrumbs.lualine.winbar is supported for the time
-being.
vim.ui.breadcrumbs.lualine.winbar.enable has been added to allow
-controlling the default behaviour of the nvim-navic component on Lualine,
-which used to occupy winbar.lualine_c as long as breadcrumbs are enabled.
Move options that used to set vim.o values (e.g. vim.wordWrap) into
-vim.options as default values. Some are left as they don’t have a direct
-equivalent, but expect a switch eventually.