mirror of
https://github.com/NotAShelf/nvf.git
synced 2026-03-04 16:02:54 +00:00
Merge branch 'main' into codewindow-open-by-default
This commit is contained in:
Yoni Firroloni
commit
a7d81331d0
185 changed files with 8088 additions and 5270 deletions
|
|
@ -92,7 +92,7 @@
|
|||
|
||||
# Generate the HTML manual pages
|
||||
html = pkgs.callPackage ./manual.nix {
|
||||
inherit release;
|
||||
inherit inputs release;
|
||||
inherit (nvimModuleDocs) optionsJSON;
|
||||
};
|
||||
in {
|
||||
|
|
|
|||
138
docs/manual.nix
138
docs/manual.nix
|
|
@ -1,114 +1,44 @@
|
|||
{
|
||||
lib,
|
||||
stdenvNoCC,
|
||||
fetchzip,
|
||||
runCommandLocal,
|
||||
# build inputs
|
||||
nixos-render-docs,
|
||||
documentation-highlighter,
|
||||
dart-sass,
|
||||
inputs,
|
||||
path,
|
||||
# nrd configuration
|
||||
release,
|
||||
stdenvNoCC,
|
||||
runCommandLocal,
|
||||
optionsJSON,
|
||||
release,
|
||||
} @ args: let
|
||||
manual-release = args.release or "unstable";
|
||||
|
||||
scss-reset = fetchzip {
|
||||
url = "https://github.com/Frontend-Layers/scss-reset/archive/refs/tags/1.4.2.zip";
|
||||
hash = "sha256-cif5Sx8Ca5vxdw/mNAgpulLH15TwmzyJFNM7JURpoaE=";
|
||||
};
|
||||
|
||||
compileStylesheet = runCommandLocal "compile-nvf-stylesheet" {} ''
|
||||
mkdir -p $out
|
||||
|
||||
tmpfile=$(mktemp -d)
|
||||
trap "rm -r $tmpfile" EXIT
|
||||
|
||||
ln -s "${scss-reset}/build" "$tmpfile/scss-reset"
|
||||
|
||||
${dart-sass}/bin/sass --load-path "$tmpfile" \
|
||||
${./static/style.scss} "$out/style.css"
|
||||
|
||||
echo "Generated styles"
|
||||
'';
|
||||
in
|
||||
stdenvNoCC.mkDerivation {
|
||||
name = "nvf-manual";
|
||||
src = builtins.path {
|
||||
name = "nvf-manual-${manual-release}";
|
||||
path = lib.sourceFilesBySuffices ./manual [".md" ".md.in"];
|
||||
};
|
||||
runCommandLocal "nvf-docs-html" {
|
||||
nativeBuildInputs = [
|
||||
(inputs.ndg.packages.${stdenvNoCC.system}.ndg.overrideAttrs
|
||||
{
|
||||
# FIXME: the tests take too long to build
|
||||
doCheck = false;
|
||||
})
|
||||
];
|
||||
} ''
|
||||
mkdir -p $out/share/doc
|
||||
|
||||
strictDependencies = true;
|
||||
nativeBuildInputs = [nixos-render-docs];
|
||||
# Copy the markdown sources to be processed by ndg. This is not
|
||||
# strictly necessary, but allows us to modify the Markdown sources
|
||||
# as we see fit.
|
||||
cp -rvf ${./manual} ./manual
|
||||
|
||||
postPatch = ''
|
||||
ln -s ${optionsJSON}/share/doc/nixos/options.json ./config-options.json
|
||||
'';
|
||||
# Replace variables following the @VARIABLE@ style in the manual
|
||||
# pages. This can be built into ndg at a later date.
|
||||
substituteInPlace ./manual/index.md \
|
||||
--subst-var-by NVF_VERSION ${manual-release}
|
||||
|
||||
buildPhase = ''
|
||||
dest="$out/share/doc/nvf"
|
||||
mkdir -p "$(dirname "$dest")"
|
||||
mkdir -p $dest/{highlightjs,script}
|
||||
# Generate the final manual from a set of parameters. This uses
|
||||
# feel-co/ndg to render the web manual.
|
||||
ndg --config-file ${./ndg.toml} html \
|
||||
--jobs $NIX_BUILD_CORES --title "NVF" \
|
||||
--module-options ${optionsJSON}/share/doc/nixos/options.json \
|
||||
--manpage-urls ${path}/doc/manpage-urls.json \
|
||||
--input-dir ./manual \
|
||||
--output-dir "$out/share/doc"
|
||||
|
||||
# Copy highlight scripts to /highlights in document root.
|
||||
cp -vt $dest/highlightjs \
|
||||
${documentation-highlighter}/highlight.pack.js \
|
||||
${documentation-highlighter}/LICENSE \
|
||||
${documentation-highlighter}/mono-blue.css \
|
||||
${documentation-highlighter}/loader.js
|
||||
|
||||
# Copy anchor scripts to the script directory in document root.
|
||||
cp -vt "$dest"/script \
|
||||
${./static/script}/anchor-min.js \
|
||||
${./static/script}/anchor-use.js \
|
||||
${./static/script}/search.js
|
||||
|
||||
substituteInPlace ./options.md \
|
||||
--subst-var-by OPTIONS_JSON ./config-options.json
|
||||
|
||||
substituteInPlace ./manual.md \
|
||||
--subst-var-by NVF_VERSION ${manual-release}
|
||||
|
||||
substituteInPlace ./hacking/additional-plugins.md \
|
||||
--subst-var-by NVF_REPO "https://github.com/notashelf/nvf/blob/${manual-release}"
|
||||
|
||||
# Move compiled stylesheet
|
||||
cp -vt $dest \
|
||||
${compileStylesheet}/style.css
|
||||
|
||||
# Move release notes
|
||||
cp -vr ${./release-notes} release-notes
|
||||
|
||||
# Generate final manual from a set of parameters. Explanation of the CLI flags are
|
||||
# as follows:
|
||||
#
|
||||
# 1. --manpage-urls will allow you to use manual pages as they are defined in
|
||||
# the nixpkgs documentation.
|
||||
# 2. --revision is the project revision as it is defined in 'release.json' in the
|
||||
# repository root
|
||||
# 3. --script will inject a given Javascript file into the resulting pages inside
|
||||
# the <script> tag.
|
||||
# 4. --toc-depth will determine the depth of the initial Table of Contents while
|
||||
# --section-toc-depth will determine the depth of per-section Table of Contents
|
||||
# sections.
|
||||
nixos-render-docs manual html \
|
||||
--manpage-urls ${path + "/doc/manpage-urls.json"} \
|
||||
--revision ${lib.trivial.revisionWithDefault manual-release} \
|
||||
--stylesheet style.css \
|
||||
--script highlightjs/highlight.pack.js \
|
||||
--script highlightjs/loader.js \
|
||||
--script script/anchor-use.js \
|
||||
--script script/anchor-min.js \
|
||||
--script script/search.js \
|
||||
--toc-depth 1 \
|
||||
--section-toc-depth 1 \
|
||||
manual.md \
|
||||
"$dest/index.xhtml"
|
||||
|
||||
# Hydra support. Probably not necessary.
|
||||
mkdir -p $out/nix-support/
|
||||
echo "doc manual $dest index.html" >> $out/nix-support/hydra-build-products
|
||||
'';
|
||||
}
|
||||
# Hydra support. Probably not necessary.
|
||||
mkdir -p $out/nix-support/
|
||||
echo "doc manual $dest index.html" >> $out/nix-support/hydra-build-products
|
||||
''
|
||||
|
|
|
|||
|
|
@ -1,14 +1,16 @@
|
|||
# Configuring nvf {#ch-configuring}
|
||||
|
||||
[helpful tips section]: #ch-helpful-tips
|
||||
[helpful tips section]: ./tips.html#ch-helpful-tips
|
||||
[options reference]: ./options.html
|
||||
|
||||
nvf allows for _very_ extensive configuration in Neovim through the Nix module
|
||||
interface. The below chapters describe several of the options exposed in nvf for
|
||||
your convenience. You might also be interested in the [helpful tips section] for
|
||||
more advanced or unusual configuration options supported by nvf.
|
||||
**nvf** allows for _very_ extensive configuration in Neovim through the Nix
|
||||
module interface. The below chapters describe several of the options exposed in
|
||||
nvf for your convenience. You might also be interested in the
|
||||
[helpful tips section] for more advanced or unusual configuration options
|
||||
supported by nvf.
|
||||
|
||||
Note that this section does not cover module _options_. For an overview of all
|
||||
module options provided by nvf, please visit the [appendix](/nvf/options.html)
|
||||
module options provided by nvf, please visit the [options reference]
|
||||
|
||||
```{=include=} chapters
|
||||
configuring/custom-package.md
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
# Custom Neovim Package {#ch-custom-package}
|
||||
|
||||
As of v0.5, you may now specify the Neovim package that will be wrapped with
|
||||
your configuration. This is done with the [](#opt-vim.package) option.
|
||||
|
||||
```nix
|
||||
{inputs, pkgs, ...}: {
|
||||
# using the neovim-nightly overlay
|
||||
vim.package = inputs.neovim-overlay.packages.${pkgs.stdenv.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.
|
||||
|
||||
```nix
|
||||
{ pkgs, ...}: {
|
||||
# using the neovim-nightly overlay
|
||||
vim.package = pkgs.neovim-unwrapped;
|
||||
}
|
||||
```
|
||||
|
|
@ -19,7 +19,7 @@ as a module.
|
|||
:::{.info}
|
||||
|
||||
To add a plugin to your runtime, you will need to add it to
|
||||
[](#opt-vim.startPlugins) list in your configuration. This is akin to cloning a
|
||||
{option}`vim.startPlugins` list in your configuration. This is akin to cloning a
|
||||
plugin to `~/.config/nvim`, but they are only ever placed in the Nix store and
|
||||
never exposed to the outside world for purity and full isolation.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ hooks should do what you need.
|
|||
```nix
|
||||
{
|
||||
config.vim.lazy.plugins = {
|
||||
aerial.nvim = {
|
||||
"aerial.nvim" = {
|
||||
# ^^^^^^^^^ this name should match the package.pname or package.name
|
||||
package = aerial-nvim;
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
# Legacy Method {#sec-legacy-method}
|
||||
|
||||
Prior to version **0.5**, the method of adding new plugins was adding the plugin
|
||||
package to [](#opt-vim.startPlugins) and adding its configuration as a DAG under
|
||||
one of `vim.configRC` or [](#opt-vim.luaConfigRC). While `configRC` has been
|
||||
deprecated, users who have not yet updated to 0.5 or those who prefer a more
|
||||
hands-on approach may choose to use the old method where the load order of the
|
||||
plugins is explicitly determined by DAGs without internal abstractions.
|
||||
package to {option}`vim.startPlugins` and adding its configuration as a DAG
|
||||
under one of `vim.configRC` or {option}`vim.luaConfigRC`. While `configRC` has
|
||||
been deprecated, users who have not yet updated to 0.5 or those who prefer a
|
||||
more hands-on approach may choose to use the old method where the load order of
|
||||
the plugins is explicitly determined by DAGs without internal abstractions.
|
||||
|
||||
## Adding New Plugins {#sec-adding-new-plugins}
|
||||
|
||||
To add a plugin not available in **nvf** as a module to your configuration using
|
||||
the legacy method, you must add it to [](#opt-vim.startPlugins) in order to make
|
||||
it available to Neovim at runtime.
|
||||
the legacy method, you must add it to {option}`vim.startPlugins` in order to
|
||||
make it available to Neovim at runtime.
|
||||
|
||||
```nix
|
||||
{pkgs, ...}: {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
As of version **0.5**, we have a more extensive API for configuring plugins that
|
||||
should be preferred over the legacy method. This API is available as
|
||||
[](#opt-vim.extraPlugins). Instead of using DAGs exposed by the library
|
||||
{option}`vim.extraPlugins`. Instead of using DAGs exposed by the library
|
||||
_directly_, you may use the extra plugin module as follows:
|
||||
|
||||
```nix
|
||||
|
|
|
|||
|
|
@ -1,25 +1,92 @@
|
|||
# Language Support {#ch-languages}
|
||||
|
||||
Language specific support means there is a combination of language specific
|
||||
plugins, `treesitter` support, `nvim-lspconfig` language servers, and `null-ls`
|
||||
integration. This gets you capabilities ranging from autocompletion to
|
||||
formatting to diagnostics. The following languages have sections under the
|
||||
`vim.languages` attribute.
|
||||
plugins, `treesitter` support, `nvim-lspconfig` language servers, `conform-nvim`
|
||||
formatters, and `nvim-lint` linter integration. This gets you capabilities
|
||||
ranging from autocompletion to formatting to diagnostics. The following
|
||||
languages have sections under the `vim.languages` attribute.
|
||||
|
||||
- Rust: [vim.languages.rust.enable](#opt-vim.languages.rust.enable)
|
||||
- Nix: [vim.languages.nix.enable](#opt-vim.languages.nix.enable)
|
||||
- SQL: [vim.languages.sql.enable](#opt-vim.languages.sql.enable)
|
||||
- C/C++: [vim.languages.clang.enable](#opt-vim.languages.clang.enable)
|
||||
- Typescript/Javascript: [vim.languages.ts.enable](#opt-vim.languages.ts.enable)
|
||||
- Python: [vim.languages.python.enable](#opt-vim.languages.python.enable):
|
||||
- Zig: [vim.languages.zig.enable](#opt-vim.languages.zig.enable)
|
||||
- Markdown: [vim.languages.markdown.enable](#opt-vim.languages.markdown.enable)
|
||||
- HTML: [vim.languages.html.enable](#opt-vim.languages.html.enable)
|
||||
- Dart: [vim.languages.dart.enable](#opt-vim.languages.dart.enable)
|
||||
- Go: [vim.languages.go.enable](#opt-vim.languages.go.enable)
|
||||
- Lua: [vim.languages.lua.enable](#opt-vim.languages.lua.enable)
|
||||
- PHP: [vim.languages.php.enable](#opt-vim.languages.php.enable)
|
||||
- F#: [vim.languages.fsharp.enable](#opt-vim.languages.fsharp.enable)
|
||||
- Rust:
|
||||
[vim.languages.rust.enable](./options.html#option-vim-languages-rust-enable)
|
||||
- Nix:
|
||||
[vim.languages.nix.enable](./options.html#option-vim-languages-nix-enable)
|
||||
- SQL:
|
||||
[vim.languages.sql.enable](./options.html#option-vim-languages-sql-enable)
|
||||
- C/C++:
|
||||
[vim.languages.clang.enable](./options.html#option-vim-languages-clang-enable)
|
||||
- Typescript/Javascript:
|
||||
[vim.languages.ts.enable](./options.html#option-vim-languages-ts-enable)
|
||||
- Python:
|
||||
[vim.languages.python.enable](./options.html#option-vim-languages-python-enable):
|
||||
- Zig:
|
||||
[vim.languages.zig.enable](./options.html#option-vim-languages-zig-enable)
|
||||
- Markdown:
|
||||
[vim.languages.markdown.enable](./options.html#option-vim-languages-markdown-enable)
|
||||
- HTML:
|
||||
[vim.languages.html.enable](./options.html#option-vim-languages-html-enable)
|
||||
- Dart:
|
||||
[vim.languages.dart.enable](./options.html#option-vim-languages-dart-enable)
|
||||
- Go: [vim.languages.go.enable](./options.html#option-vim-languages-go-enable)
|
||||
- Lua:
|
||||
[vim.languages.lua.enable](./options.html#option-vim-languages-lua-enable)
|
||||
- PHP:
|
||||
[vim.languages.php.enable](./options.html#option-vim-languages-php-enable)
|
||||
- F#:
|
||||
[vim.languages.fsharp.enable](./options.html#option-vim-languages-fsharp-enable)
|
||||
- Assembly:
|
||||
[vim.languages.assembly.enable](./options.html#option-vim-languages-assembly-enable)
|
||||
- Astro:
|
||||
[vim.languages.astro.enable](./options.html#option-vim-languages-astro-enable)
|
||||
- Bash:
|
||||
[vim.languages.bash.enable](./options.html#option-vim-languages-bash-enable)
|
||||
- Clang:
|
||||
[vim.languages.clang.enable](./options.html#option-vim-languages-clang-enable)
|
||||
- Clojure:
|
||||
[vim.languages.clojure.enable](./options.html#option-vim-languages-clojure-enable)
|
||||
- C#:
|
||||
[vim.languages.csharp.enable](./options.html#option-vim-languages-csharp-enable)
|
||||
- CSS:
|
||||
[vim.languages.css.enable](./options.html#option-vim-languages-css-enable)
|
||||
- CUE:
|
||||
[vim.languages.cue.enable](./options.html#option-vim-languages-cue-enable)
|
||||
- Elixir:
|
||||
[vim.languages.elixir.enable](./options.html#option-vim-languages-elixir-enable)
|
||||
- Gleam:
|
||||
[vim.languages.gleam.enable](./options.html#option-vim-languages-gleam-enable)
|
||||
- HCL:
|
||||
[vim.languages.hcl.enable](./options.html#option-vim-languages-hcl-enable)
|
||||
- Helm:
|
||||
[vim.languages.helm.enable](./options.html#option-vim-languages-helm-enable)
|
||||
- Julia:
|
||||
[vim.languages.julia.enable](./options.html#option-vim-languages-julia-enable)
|
||||
- Kotlin:
|
||||
[vim.languages.kotlin.enable](./options.html#option-vim-languages-kotlin-enable)
|
||||
- Nim:
|
||||
[vim.languages.nim.enable](./options.html#option-vim-languages-nim-enable)
|
||||
- Nu: [vim.languages.nu.enable](./options.html#option-vim-languages-nu-enable)
|
||||
- OCaml:
|
||||
[vim.languages.ocaml.enable](./options.html#option-vim-languages-ocaml-enable)
|
||||
- Odin:
|
||||
[vim.languages.odin.enable](./options.html#option-vim-languages-odin-enable)
|
||||
- R: [vim.languages.r.enable](./options.html#option-vim-languages-r-enable)
|
||||
- Ruby:
|
||||
[vim.languages.ruby.enable](./options.html#option-vim-languages-ruby-enable)
|
||||
- Scala:
|
||||
[vim.languages.scala.enable](./options.html#option-vim-languages-scala-enable)
|
||||
- Svelte:
|
||||
[vim.languages.svelte.enable](./options.html#option-vim-languages-svelte-enable)
|
||||
- Tailwind:
|
||||
[vim.languages.tailwind.enable](./options.html#option-vim-languages-tailwind-enable)
|
||||
- Terraform:
|
||||
[vim.languages.terraform.enable](./options.html#option-vim-languages-terraform-enable)
|
||||
- Typst:
|
||||
[vim.languages.typst.enable](./options.html#option-vim-languages-typst-enable)
|
||||
- Vala:
|
||||
[vim.languages.vala.enable](./options.html#option-vim-languages-vala-enable)
|
||||
- WGSL:
|
||||
[vim.languages.wgsl.enable](./options.html#option-vim-languages-wgsl-enable)
|
||||
- YAML:
|
||||
[vim.languages.yaml.enable](./options.html#option-vim-languages-yaml-enable)
|
||||
|
||||
Adding support for more languages, and improving support for existing ones are
|
||||
great places where you can contribute with a PR.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Overriding plugins {#ch-overriding-plugins}
|
||||
|
||||
The [additional plugins section](#sec-additional-plugins) 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**.
|
||||
The [additional plugins section](./hacking.html#sec-additional-plugins) 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**.
|
||||
|
||||
```nix
|
||||
vim.pluginOverrides = {
|
||||
|
|
@ -22,7 +22,7 @@ vim.pluginOverrides = {
|
|||
};
|
||||
```
|
||||
|
||||
This will override the source for the `neodev.nvim` plugin that is used in nvf
|
||||
This will override the source for the `lazydev.nvim` plugin that is used in nvf
|
||||
with your own plugin.
|
||||
|
||||
::: {.warning}
|
||||
|
|
|
|||
|
|
@ -3,12 +3,13 @@
|
|||
[open issues]: https://github.com/notashelf/nvf/issues
|
||||
[new issue]: https://github.com/notashelf/nvf/issues/new
|
||||
|
||||
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.
|
||||
**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
|
||||
|
|
@ -21,10 +22,803 @@ 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.
|
||||
|
||||
```{=include=} sections
|
||||
hacking/getting-started.md
|
||||
hacking/guidelines.md
|
||||
hacking/testing.md
|
||||
hacking/keybinds.md
|
||||
hacking/additional-plugins.md
|
||||
## Getting Started {#sec-contrib-getting-started}
|
||||
|
||||
[Fork a repo guide]: https://help.github.com/articles/fork-a-repo/
|
||||
[Contributing Guidelines]: #sec-guidelines
|
||||
[Create a Pull Request]: https://help.github.com/articles/creating-a-pull-request
|
||||
|
||||
To contribute to **nvf**, you'll first want to fork the repository. 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 your fork is created, you should
|
||||
create a separate branch based on the most recent `main` branch. While you _can_
|
||||
work on the main branch of your repository, it is generally preferable to use
|
||||
feature branches. You should give your branch a reasonably descriptive name
|
||||
(e.g. `feature/new-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.
|
||||
|
||||
Before submitting your pull request, please ensure that:
|
||||
|
||||
- The code is formatted as described in the formatting section
|
||||
- The commit message fits the contributing guidelines (**nvf** does not use
|
||||
Conventional Commits!)
|
||||
- You have updated the changelog entry and optionally updated the documentation
|
||||
with important information
|
||||
|
||||
None of those are reasons for a Pull Request to be closed, but it will reduce
|
||||
the number of "roundtrips", or rather, the back-and-forth required before we can
|
||||
merge your Pull Request.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If you do not agree with the idea of using Microsoft GitHub for contributions,
|
||||
> that is perfectly understandable. Unless you refuse to have your code hosted
|
||||
> on this platform, you may submit _patches_ through e-mail.
|
||||
>
|
||||
> You may send your patches to [@NotAShelf](https://github.com/notashelf) using
|
||||
> the public e-mail located on the GitHub page. Though, please remember to
|
||||
> adhere to the contributing guidelines strictly, as e-mail introduces a
|
||||
> significant overhead to the communication process.
|
||||
|
||||
## Guidelines {#sec-guidelines}
|
||||
|
||||
[discussions tab]: https://github.com/NotAShelf/nvf/discussions
|
||||
|
||||
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 not quite certain how those rules affect the change you are planning
|
||||
to make, then please start a friendly discussion in the [discussions tab] before
|
||||
you begin developing. This is not a requirement, but it might answer some of
|
||||
your burning questions and make the contribution process easier for all parties.
|
||||
|
||||
### Formatting {#sec-guidelines-formatting}
|
||||
|
||||
[code style section]: #sec-guidelines-code-style
|
||||
|
||||
There are various files within the **nvf** repository. To maintain a sense of
|
||||
consistency and to avoid clashing opinions on how formatters should behave, we
|
||||
are very opinionated on how those files should be formatted.
|
||||
|
||||
- Nix files **must** be formatted with the Alejandra formatter, following some
|
||||
specific tips found in [Nix style section](#nix-sec-code-style-nix).
|
||||
- Markdown files **must** be formatted with the `deno fmt` command, as described
|
||||
in the [Markdown style section](#sec-code-style-markdown).
|
||||
|
||||
Make sure your code is formatted as described in [code style section] before
|
||||
your changes are submitted.
|
||||
|
||||
### Formatting Commits {#sec-guidelines-commit-message-style}
|
||||
|
||||
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a
|
||||
consistent commit message format as described in
|
||||
[commit style guidelines](#sec-guidelines-commit-style).
|
||||
|
||||
### Commit Style {#sec-guidelines-commit-style}
|
||||
|
||||
The commits in your pull request should be reasonably self-contained. Which
|
||||
means each and every commit in a pull request should make sense both on its own
|
||||
and in general context. That is, a second commit should not resolve an issue
|
||||
that is introduced in an earlier commit. In particular, you will be asked to
|
||||
amend any commit that introduces syntax errors or similar problems even if they
|
||||
are fixed in a later commit.
|
||||
|
||||
The commit messages should follow the
|
||||
[seven rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
|
||||
"Capitalize the subject line". We also ask you to include the affected code
|
||||
component or module in the first line. A commit message ideally, but not
|
||||
necessarily, follow the given template from home-manager's own documentation
|
||||
|
||||
```gitcommit
|
||||
{component}: {description}
|
||||
|
||||
{long description}
|
||||
```
|
||||
|
||||
where `{component}` refers to the code component (or module) your change
|
||||
affects, `{description}` is a very brief description of your change, and
|
||||
`{long description}` is an optional clarifying description.
|
||||
|
||||
[example commit message]: #sec-guidelines-ex-commit-message
|
||||
|
||||
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.
|
||||
|
||||
#### Example Commit {#sec-guidelines-ex-commit-message}
|
||||
|
||||
[sample commit from Home Manager]: https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef
|
||||
|
||||
The [sample commit from Home Manager] contains the following commit message.
|
||||
|
||||
```gitcommit
|
||||
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:
|
||||
|
||||
```gitcommit
|
||||
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 for your commit.
|
||||
|
||||
For new plugin additions, the following is a good starting point:
|
||||
|
||||
```gitcommit
|
||||
plugin: init
|
||||
```
|
||||
|
||||
You can, of course, still include a long description if you wish.
|
||||
|
||||
```gitcommit
|
||||
neotree: init
|
||||
|
||||
This adds the neo-tree plugin.
|
||||
```
|
||||
|
||||
In case of nested modules, e.g., `modules/languages/java.nix` you are
|
||||
recommended to contain the parent as well -- for example
|
||||
`languages/java: some major change` , or if it's a new language module,
|
||||
`languages/java: init`
|
||||
|
||||
### Code Style {#sec-guidelines-code-style}
|
||||
|
||||
#### Treewide {#sec-code-style-treewide}
|
||||
|
||||
Across the tree, you're encouraged to follow kebab-case for file names, and keep
|
||||
text files (such as Markdown) to 80 characters or less. This 80 character
|
||||
recommendation also applies to option descriptions and string literals inside of
|
||||
Nix files.
|
||||
|
||||
#### Markdown {#sec-code-style-markdown}
|
||||
|
||||
Various Markdown files are used for documentation in the **nvf** repository.
|
||||
Besides the README, the manual is written almost entirely in Markdown. Since
|
||||
**nvf** uses a special variant of CommonMark, dubbed "Nixpkgs-flavored
|
||||
CommonMark" within this repository, you are encouraged to use the `deno fmt`
|
||||
command (provided by `pkgs.deno`) to format your Markdown sources. To avoid
|
||||
accidentally formatting HTML or CSS files, you might want to specify the file
|
||||
extension as follows:
|
||||
|
||||
```bash
|
||||
# Format all Markdown files within the repository
|
||||
$ deno fmt --ext md **/*.md
|
||||
```
|
||||
|
||||
You may also pass `--check` to the `deno fmt` command above to see if your
|
||||
formatting complies with the project standards.
|
||||
|
||||
#### Nix {#sec-code-style-nix}
|
||||
|
||||
[alejandra]: https://github.com/kamadorueda/alejandra
|
||||
|
||||
**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.
|
||||
|
||||
##### Attribute Sets
|
||||
|
||||
Please use one line code for attribute sets that contain only one subset. For
|
||||
example:
|
||||
|
||||
<!-- markdownlint-disable MD013 -->
|
||||
|
||||
```nix
|
||||
# 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";
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
<!-- markdownlint-enable MD013 -->
|
||||
|
||||
If you move a line down after the merge operator, Alejandra will automatically
|
||||
unfold the whole merged attribute set for you, which we **do not** want.
|
||||
|
||||
```nix
|
||||
module = {
|
||||
# This is wrong!
|
||||
key = mkEnableOption "some description" // {
|
||||
default = true; # we want this to be inline
|
||||
};
|
||||
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
Though, if the right-hand side is more than a single line, it is okay to move to
|
||||
a new line. For example:
|
||||
|
||||
```nix
|
||||
module = {
|
||||
# This is okay!
|
||||
key = mkEnableOption "some description" // {
|
||||
default = true;
|
||||
example = false;
|
||||
};
|
||||
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
##### Lists
|
||||
|
||||
For lists, it is mostly up to your own discretion how you want to format them,
|
||||
but please try to unfold lists if they contain multiple items and especially if
|
||||
they are to include comments.
|
||||
|
||||
```nix
|
||||
# This is ok
|
||||
acceptableList = [
|
||||
item1 # comment
|
||||
item2
|
||||
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 {#sec-testing-changes}
|
||||
|
||||
Once you have made your changes, you will need to test them thoroughly. To make
|
||||
testing easier you may either use the `configuration.nix` located in the
|
||||
repository root, or use the development package located in `flake/develop.nix`.
|
||||
The development package allows you to quickly bootstrap a Neovim configuration
|
||||
with only the required modules, instead of the packages that consume the
|
||||
`configuration.nix`, so it is generally preferable. To use it navigate to the
|
||||
`develop.nix` module, and update the `configuration` set with the Neovim
|
||||
configuration that you would like to test with. For example:
|
||||
|
||||
```nix
|
||||
{
|
||||
# Let's assume you are adding a new module for the Nix language.
|
||||
# You will need to enable it here
|
||||
configuration = {
|
||||
vim.languages.nix.enable = true;
|
||||
|
||||
# You can also enable other plugins that you wish to test with, for example
|
||||
# none-ls:
|
||||
vim.lsp.null-ls = {
|
||||
enable = true;
|
||||
setupOpts = { /* Your setup options here */ };
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
You may then run this package with `nix run .#develop` and check for build or
|
||||
runtime errors. If Neovim builds and opens without any errors, then your changes
|
||||
are good to go. Open your pull request, and it will be reviewed as soon as
|
||||
possible.
|
||||
|
||||
If your changes are rather large, or if you would like to instead test with a
|
||||
more complex configuration then you might use the `configuration.nix` for
|
||||
testing. Make your changes, and then build either the default or `maximal`
|
||||
package to test your changes.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> `configuration.nix` is a module used to bootstrap **demo** packages and should
|
||||
> generally not be changed unless migrating old APIs or updating the set of
|
||||
> default plugins. Similarly, the `develop.nix` file is for reference, and
|
||||
> testing configurations **should not be committed**.
|
||||
|
||||
## Adding Documentation {#sec-guidelines-documentation}
|
||||
|
||||
[Nixpkgs Flavoured Markdown]: https://github.com/NixOS/nixpkgs/blob/master/doc/README.md#syntax
|
||||
[in-house documentation generator]: https://github.com/feel-co/ndg
|
||||
[library documentation]: https://github.com/feel-co/ndg/blob/main/ndg-commonmark/docs/SYNTAX.md
|
||||
|
||||
Almost all changes to **nvf**'s codebase warrant updates to the documentation.
|
||||
At the very least, you must update the relevant changelog document to describe
|
||||
your changes. The documentation files found within the repository use a superset
|
||||
of [Nixpkgs Flavoured Markdown] thanks to our
|
||||
[in-house documentation generator].
|
||||
|
||||
As a general rule of thumb:
|
||||
|
||||
- Everything in the CommonMark spec is supported
|
||||
- Everything in Nixpkgs Flavoured Markdown is supported
|
||||
- Github Flavored Markdown is supported for Tables and Admonitions
|
||||
|
||||
By feeding NDG, our documentation generator, Markdown sources we can generate a
|
||||
HTML manual with various goodies, including a **search page** and an **options
|
||||
page**. The latter, found under `options.html` contains module options, similar
|
||||
to the official Nixpkgs search utility. The supported syntax for NDG can be
|
||||
found over at the [library documentation].
|
||||
|
||||
### Building the Documentation
|
||||
|
||||
The HTML version of this documentation, dubbed the "nvf manual", can be
|
||||
generated and opened by typing the following in a shell within a clone of the
|
||||
**nvf** Git repository:
|
||||
|
||||
```sh
|
||||
# Build the online manual
|
||||
$ nix build .#docs-html
|
||||
|
||||
# Open it with a valid browser
|
||||
$ xdg-open $PWD/result/share/doc/index.html
|
||||
```
|
||||
|
||||
Additionally, if you are adding new links to the documentation it is **generally
|
||||
recommended** that you run the package that identifies dead URLs in the
|
||||
documentation:
|
||||
|
||||
```sh
|
||||
# Build the link checker package
|
||||
$ nix build .#docs-linkcheck
|
||||
```
|
||||
|
||||
You must ensure that the **HTML Documentation** builds before submitting a pull
|
||||
request. If the documentation builds, an automatic "preview" build will be
|
||||
deployed automatically for your Pull Request. You may use this preview to view
|
||||
your changes as your Pull Request is updated.
|
||||
|
||||
### Formatting Changelog Entries
|
||||
|
||||
For additions, removals or any general change that concerns the users you must
|
||||
add a changelog entry. The changelog entries are later included in the rendered
|
||||
manual for users hoping to learn what has changed.
|
||||
|
||||
To maintain consistency, you must follow the following format in the changelog:
|
||||
|
||||
```markdown
|
||||
[username](https://github.com/username):
|
||||
|
||||
- Added ...
|
||||
- Removed ...
|
||||
- Changed ...
|
||||
```
|
||||
|
||||
If this is your first contribution, you should add yourself to the changelog.
|
||||
Linking your GitHub account is not a strict requirement; it can be any page that
|
||||
people can use to discover you. Below the link to your profile, you should
|
||||
include a brief description of your changes. Those descriptions must be in past
|
||||
tense, unlike commit messages.
|
||||
|
||||
While adding a new section, please insert the section at an arbitrary location
|
||||
under the `## Changelog` section rather than the end of the document. This helps
|
||||
avoid merge conflicts.
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
If you are introducing _breaking_ changes to the repository, then you must also
|
||||
briefly mention what has changed in the breaking changes section of the
|
||||
changelog document that you are editing. If this section does not yet exist, you
|
||||
must create it.
|
||||
|
||||
```markdown
|
||||
# Release 0.9 {#sec-release-0-9}
|
||||
|
||||
## Breaking changes
|
||||
|
||||
- We broke everything, please migrate!
|
||||
```
|
||||
|
||||
This section is _critical_, as it is used to communicate to the users what has
|
||||
changed in the codebase and what breakage they may expect upon an update. To be
|
||||
comprehensive, you should include migration steps or how users may mitigate
|
||||
breakage depending on the context of the change.
|
||||
|
||||
## Adding Plugins {#sec-additional-plugins}
|
||||
|
||||
**nvf** generally tries to avoid using Neovim plugins from Nixpkgs, and thus
|
||||
uses one of the two alternative methods where applicable. npins is the faster
|
||||
option that should be preferred if the plugin consists of pure Lua or Vimscript
|
||||
code. In which case there is no building required, and we can easily handle the
|
||||
copying of plugin files. Alternative method, which is required when plugins try
|
||||
to build their own libraries (e.g., in Rust, C or even Assembly) that need to be
|
||||
built with Nix to function correctly. In this case you must use a local overlay.
|
||||
|
||||
### With npins {#sec-npins-for-plugins}
|
||||
|
||||
npins is the standard, and as described above, the _faster_ method of adding new
|
||||
plugins to **nvf**. You simply need the repository URL for the plugin, and you
|
||||
can add it as a source to be built automatically with just one command. To add a
|
||||
new Neovim plugin, use `npins`. For example:
|
||||
|
||||
```bash
|
||||
nix-shell -p npins # or nix shell nixpkgs#npins if using flakes
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
```bash
|
||||
npins add --name <plugin name> github <owner> <repo> -b <branch>
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Be sure to replace any non-alphanumeric characters with `-` for `--name`. For
|
||||
> example
|
||||
>
|
||||
> ```bash
|
||||
> npins add --name lazydev-nvim github folke lazydev.nvim -b main
|
||||
> ```
|
||||
|
||||
Once the `npins` command is done, you can start referencing the plugin as a
|
||||
**string**.
|
||||
|
||||
```nix
|
||||
{
|
||||
config.vim.startPlugins = ["lazydev-nvim"];
|
||||
}
|
||||
```
|
||||
|
||||
### Packaging Complex Plugins {#sec-pkgs-for-plugins}
|
||||
|
||||
[blink.cmp]: https://github.com/Saghen/blink.cmp
|
||||
|
||||
Some plugins require additional packages to be built and substituted to function
|
||||
correctly. For example [blink.cmp] requires its own fuzzy matcher library, built
|
||||
with Rust, to be installed or else defaults to a much slower Lua implementation.
|
||||
In the Blink documentation, you are advised to build with `cargo` but that is
|
||||
not ideal since we are leveraging the power of Nix. In this case the ideal
|
||||
solution is to write a derivation for the plugin.
|
||||
|
||||
We use `buildRustPackage` to build the library from the repository root, and
|
||||
copy everything in the `postInstall` phase.
|
||||
|
||||
```nix
|
||||
{
|
||||
# ...
|
||||
|
||||
postInstall = ''
|
||||
cp -r {lua,plugin} "$out"
|
||||
|
||||
mkdir -p "$out/doc"
|
||||
cp 'doc/'*'.txt' "$out/doc/"
|
||||
|
||||
mkdir -p "$out/target"
|
||||
mv "$out/lib" "$out/target/release"
|
||||
'';
|
||||
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
In a similar fashion, you may utilize `stdenv.mkDerivation` and other Nixpkgs
|
||||
builders to build your library from source, and copy the relevant files and Lua
|
||||
plugin files in the `postInstall` phase. Do note, however, that you still need
|
||||
to fetch the plugin sources somehow. npins is, once again, the recommended
|
||||
option to fetch the plugin sources. Refer to the previous section on how to use
|
||||
npins to add a new plugin.
|
||||
|
||||
Plugins built from source must go into the `flake/pkgs/by-name` overlay. It will
|
||||
automatically create flake outputs for individual packages. Lastly, you must add
|
||||
your package to the plugin builder (`pluginBuilders`) function manually in
|
||||
`modules/wrapper/build/config.nix`. Once done, you may refer to your plugin as a
|
||||
**string**.
|
||||
|
||||
```nix
|
||||
{
|
||||
config.vim.startPlugins = ["blink-cmp"];
|
||||
}
|
||||
```
|
||||
|
||||
### Modular Setup Options {#sec-modular-setup-options}
|
||||
|
||||
Most plugins is initialized with a call to `require('plugin').setup({...})`.
|
||||
|
||||
We use a special function that lets you easily add support for such setup
|
||||
options in a modular way: `mkPluginSetupOption`.
|
||||
|
||||
Once you have added the source of the plugin as shown above, you can define the
|
||||
setup options like this:
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/your-plugin.nix
|
||||
|
||||
{lib, ...}:
|
||||
let
|
||||
inherit (lib.types) bool int;
|
||||
inherit (lib.nvim.types) mkPluginSetupOption;
|
||||
in {
|
||||
options.vim.your-plugin = {
|
||||
setupOpts = mkPluginSetupOption "plugin name" {
|
||||
enable_feature_a = mkOption {
|
||||
type = bool;
|
||||
default = false;
|
||||
# ...
|
||||
};
|
||||
|
||||
number_option = mkOption {
|
||||
type = int;
|
||||
default = 3;
|
||||
# ...
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/config.nix
|
||||
{lib, config, ...}:
|
||||
let
|
||||
cfg = config.vim.your-plugin;
|
||||
in {
|
||||
vim.luaConfigRC = lib.nvim.dag.entryAnywhere ''
|
||||
require('plugin-name').setup(${lib.nvim.lua.toLuaObject cfg.setupOpts})
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
This above config will result in this Lua script:
|
||||
|
||||
```lua
|
||||
require('plugin-name').setup({
|
||||
enable_feature_a = false,
|
||||
number_option = 3,
|
||||
})
|
||||
```
|
||||
|
||||
Now users can set any of the pre-defined option field, and can also add their
|
||||
own fields!
|
||||
|
||||
```nix
|
||||
# in user's config
|
||||
{
|
||||
vim.your-plugin.setupOpts = {
|
||||
enable_feature_a = true;
|
||||
number_option = 4;
|
||||
another_field = "hello";
|
||||
size = { # nested fields work as well
|
||||
top = 10;
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Details of `toLuaObject` {#sec-details-of-toluaobject}
|
||||
|
||||
As you've seen above, `toLuaObject` is used to convert our nix attrSet
|
||||
`cfg.setupOpts`, into a lua table. Here are some rules of the conversion:
|
||||
|
||||
1. Nix `null` converts to lua `nil`
|
||||
2. Number and strings convert to their lua counterparts
|
||||
3. Nix attribute sets (`{}`) and lists (`[]`) convert into Lua dictionaries and
|
||||
tables respectively. Here is an example of Nix -> Lua conversion.
|
||||
- `{foo = "bar"}` -> `{["foo"] = "bar"}`
|
||||
- `["foo" "bar"]` -> `{"foo", "bar"}`
|
||||
4. You can write raw Lua code using `lib.generators.mkLuaInline`. This function
|
||||
is part of nixpkgs, and is accessible without relying on **nvf**'s extended
|
||||
library.
|
||||
- `mkLuaInline "function add(a, b) return a + b end"` will yield the
|
||||
following result:
|
||||
|
||||
```nix
|
||||
{
|
||||
_type = "lua-inline";
|
||||
expr = "function add(a, b) return a + b end";
|
||||
}
|
||||
```
|
||||
|
||||
The above expression will be interpreted as a Lua expression in the final
|
||||
config. Without the `mkLuaInline` function, you will only receive a string
|
||||
literal. You can use it to feed plugin configuration tables Lua functions
|
||||
that return specific values as expected by the plugins.
|
||||
|
||||
```nix
|
||||
{
|
||||
vim.your-plugin.setupOpts = {
|
||||
on_init = lib.generators.mkLuaInline ''
|
||||
function()
|
||||
print('we can write lua!')
|
||||
end
|
||||
'';
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Lazy Loading Plugins {#sec-lazy-plugins}
|
||||
|
||||
If the plugin can be lazy-loaded, `vim.lazy.plugins` should be used to add it.
|
||||
Lazy plugins are managed by `lz.n`.
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/config.nix
|
||||
{config, ...}: let
|
||||
cfg = config.vim.your-plugin;
|
||||
in {
|
||||
vim.lazy.plugins.your-plugin = {
|
||||
# Instead of vim.startPlugins, use this:
|
||||
package = "your-plugin";
|
||||
|
||||
# ıf your plugin uses the `require('your-plugin').setup{...}` pattern
|
||||
setupModule = "your-plugin";
|
||||
inherit (cfg) setupOpts;
|
||||
|
||||
# Events that trigger this plugin to be loaded
|
||||
event = ["DirChanged"];
|
||||
cmd = ["YourPluginCommand"];
|
||||
|
||||
# Plugin Keymaps
|
||||
keys = [
|
||||
# We'll cover this in detail in the 'keybinds' section
|
||||
{
|
||||
key = "<leader>d";
|
||||
mode = "n";
|
||||
action = ":YourPluginCommand";
|
||||
}
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
This results in the following lua code:
|
||||
|
||||
```lua
|
||||
require('lz.n').load({
|
||||
{
|
||||
"name-of-your-plugin",
|
||||
after = function()
|
||||
require('your-plugin').setup({
|
||||
--[[ your setupOpts ]]--
|
||||
})
|
||||
end,
|
||||
|
||||
event = {"DirChanged"},
|
||||
cmd = {"YourPluginCommand"},
|
||||
keys = {
|
||||
{"<leader>d", ":YourPluginCommand", mode = {"n"}},
|
||||
},
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
[`vim.lazy.plugins` spec]: ./options.html#option-vim-lazy-plugins
|
||||
|
||||
A full list of options can be found in the [`vim.lazy.plugins` spec] on the
|
||||
rendered manual.
|
||||
|
||||
## Keybinds {#sec-keybinds}
|
||||
|
||||
[extended standard library]: https://github.com/NotAShelf/nvf/tree/main/lib
|
||||
|
||||
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 {#sec-custom-key-mappings}
|
||||
|
||||
To set a mapping, you should define it in `vim.keymaps`. As an example, a simple
|
||||
keybinding can look like this:
|
||||
|
||||
```nix
|
||||
{
|
||||
vim.keymaps = [
|
||||
{
|
||||
key = "<leader>wq";
|
||||
mode = ["n"];
|
||||
action = ":wq<CR>";
|
||||
silent = true;
|
||||
desc = "Save file and quit";
|
||||
}
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
[module option documentation]: options.html#option-vim-keymaps
|
||||
|
||||
There are many other settings available in the keymap module. Please refer to
|
||||
the [module option documentation] for a full and up-to-date list of them.
|
||||
|
||||
To make adding new keymaps for your favorite plugins easier, **nvf** provides a
|
||||
helper function. This is so that you do not have to write the mapping attribute
|
||||
sets every time:
|
||||
|
||||
- `mkKeymap`, which mimics Neovim's `vim.keymap.set` function
|
||||
|
||||
You can read the source code of some modules to see them in action, but the
|
||||
usage should look something like this:
|
||||
|
||||
```nix
|
||||
# pluginDefinition.nix
|
||||
{lib, ...}: let
|
||||
inherit (lib.options) mkEnableOption;
|
||||
inherit (lib.nvim.binds) mkMappingOption;
|
||||
in {
|
||||
options.vim.plugin = {
|
||||
enable = mkEnableOption "Enable plugin";
|
||||
|
||||
# Mappings should always be inside an attrset called mappings
|
||||
mappings = {
|
||||
workspaceDiagnostics = mkMappingOption "Workspace diagnostics [trouble]" "<leader>lwd";
|
||||
documentDiagnostics = mkMappingOption "Document diagnostics [trouble]" "<leader>ld";
|
||||
lspReferences = mkMappingOption "LSP References [trouble]" "<leader>lr";
|
||||
quickfix = mkMappingOption "QuickFix [trouble]" "<leader>xq";
|
||||
locList = mkMappingOption "LOCList [trouble]" "<leader>xl";
|
||||
symbols = mkMappingOption "Symbols [trouble]" "<leader>xs";
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
<!-- markdownlint-disable MD013 -->
|
||||
|
||||
```nix
|
||||
# config.nix
|
||||
{
|
||||
config,
|
||||
lib,
|
||||
options,
|
||||
...
|
||||
}: let
|
||||
inherit (lib.modules) mkIf;
|
||||
inherit (lib.nvim.binds) mkKeymap;
|
||||
|
||||
cfg = config.vim.plugin;
|
||||
|
||||
keys = cfg.mappings;
|
||||
inherit (options.vim.lsp.trouble) mappings;
|
||||
in {
|
||||
config = mkIf cfg.enable {
|
||||
vim.keymaps = [
|
||||
(mkKeymap "n" keys.workspaceDiagnostics "<cmd>Trouble toggle diagnostics<CR>" {desc = mappings.workspaceDiagnostics.description;})
|
||||
(mkKeymap "n" keys.documentDiagnostics "<cmd>Trouble toggle diagnostics filter.buf=0<CR>" {desc = mappings.documentDiagnostics.description;})
|
||||
(mkKeymap "n" keys.lspReferences "<cmd>Trouble toggle lsp_references<CR>" {desc = mappings.lspReferences.description;})
|
||||
(mkKeymap "n" keys.quickfix "<cmd>Trouble toggle quickfix<CR>" {desc = mappings.quickfix.description;})
|
||||
(mkKeymap "n" keys.locList "<cmd>Trouble toggle loclist<CR>" {desc = mappings.locList.description;})
|
||||
(mkKeymap "n" keys.symbols "<cmd>Trouble toggle symbols<CR>" {desc = mappings.symbols.description;})
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
<!-- markdownlint-enable MD013 -->
|
||||
|
||||
> [!TIP]
|
||||
> If you have come across a plugin that has an API that doesn't seem to easily
|
||||
> allow custom keybindings, don't be scared to implement a draft PR. We'll help
|
||||
> you get it done.
|
||||
|
|
|
|||
|
|
@ -1,266 +0,0 @@
|
|||
# Adding Plugins {#sec-additional-plugins}
|
||||
|
||||
There are two methods for adding new Neovim plugins to **nvf**. npins is the
|
||||
faster option that should be preferred if the plugin consists of pure Lua or
|
||||
Vimscript code. In which case there is no building required, and we can easily
|
||||
handle the copying of plugin files. Alternative method, which is required when
|
||||
plugins try to build their own libraries (e.g., in Rust or C) that need to be
|
||||
built with Nix to function correctly.
|
||||
|
||||
## With npins {#sec-npins-for-plugins}
|
||||
|
||||
npins is the standard method of adding new plugins to **nvf**. You simply need
|
||||
the repository URL for the plugin, and can add it as a source to be built
|
||||
automatically with one command. To add a new Neovim plugin, use `npins`. For
|
||||
example:
|
||||
|
||||
```bash
|
||||
nix-shell -p npins # or nix shell nixpkgs#npins if using flakes
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
```bash
|
||||
npins add --name <plugin name> github <owner> <repo> -b <branch>
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
|
||||
Be sure to replace any non-alphanumeric characters with `-` for `--name`. For
|
||||
example
|
||||
|
||||
```bash
|
||||
npins add --name lazydev-nvim github folke lazydev.nvim -b main
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
Once the `npins` command is done, you can start referencing the plugin as a
|
||||
**string**.
|
||||
|
||||
```nix
|
||||
{
|
||||
config.vim.startPlugins = ["lazydev-nvim"];
|
||||
}
|
||||
```
|
||||
|
||||
## Packaging Complex Plugins {#sec-pkgs-for-plugins}
|
||||
|
||||
[blink.cmp]: https://github.com/Saghen/blink.cmp
|
||||
|
||||
Some plugins require additional packages to be built and substituted to function
|
||||
correctly. For example [blink.cmp] requires its own fuzzy matcher library, built
|
||||
with Rust, to be installed or else defaults to a much slower Lua implementation.
|
||||
In the Blink documentation, you are advised to build with `cargo` but that is
|
||||
not ideal since we are leveraging the power of Nix. In this case the ideal
|
||||
solution is to write a derivation for the plugin.
|
||||
|
||||
We use `buildRustPackage` to build the library from the repository root, and
|
||||
copy everything in the `postInstall` phase.
|
||||
|
||||
```nix
|
||||
postInstall = ''
|
||||
cp -r {lua,plugin} "$out"
|
||||
|
||||
mkdir -p "$out/doc"
|
||||
cp 'doc/'*'.txt' "$out/doc/"
|
||||
|
||||
mkdir -p "$out/target"
|
||||
mv "$out/lib" "$out/target/release"
|
||||
'';
|
||||
```
|
||||
|
||||
In a similar fashion, you may utilize `stdenv.mkDerivation` and other Nixpkgs
|
||||
builders to build your library from source, and copy the relevant files and Lua
|
||||
plugin files in the `postInstall` phase. Do note, however, that you still need
|
||||
to fetch the plugin sources somehow. npins is, once again, the recommended
|
||||
option to fetch the plugin sources. Refer to the previous section on how to use
|
||||
npins to add a new plugin.
|
||||
|
||||
Plugins built from source must go into the `flake/pkgs/by-name` overlay. It will
|
||||
automatically create flake outputs for individual packages. Lastly, you must add
|
||||
your package to the plugin builder (`pluginBuilders`) function manually in
|
||||
`modules/wrapper/build/config.nix`. Once done, you may refer to your plugin as a
|
||||
**string**.
|
||||
|
||||
```nix
|
||||
{
|
||||
config.vim.startPlugins = ["blink-cmp"];
|
||||
}
|
||||
```
|
||||
|
||||
## Modular setup options {#sec-modular-setup-options}
|
||||
|
||||
Most plugins is initialized with a call to `require('plugin').setup({...})`.
|
||||
|
||||
We use a special function that lets you easily add support for such setup
|
||||
options in a modular way: `mkPluginSetupOption`.
|
||||
|
||||
Once you have added the source of the plugin as shown above, you can define the
|
||||
setup options like this:
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/your-plugin.nix
|
||||
|
||||
{lib, ...}:
|
||||
let
|
||||
inherit (lib.types) bool int;
|
||||
inherit (lib.nvim.types) mkPluginSetupOption;
|
||||
in {
|
||||
options.vim.your-plugin = {
|
||||
setupOpts = mkPluginSetupOption "plugin name" {
|
||||
enable_feature_a = mkOption {
|
||||
type = bool;
|
||||
default = false;
|
||||
# ...
|
||||
};
|
||||
|
||||
number_option = mkOption {
|
||||
type = int;
|
||||
default = 3;
|
||||
# ...
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/config.nix
|
||||
{lib, config, ...}:
|
||||
let
|
||||
cfg = config.vim.your-plugin;
|
||||
in {
|
||||
vim.luaConfigRC = lib.nvim.dag.entryAnywhere ''
|
||||
require('plugin-name').setup(${lib.nvim.lua.toLuaObject cfg.setupOpts})
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
This above config will result in this Lua script:
|
||||
|
||||
```lua
|
||||
require('plugin-name').setup({
|
||||
enable_feature_a = false,
|
||||
number_option = 3,
|
||||
})
|
||||
```
|
||||
|
||||
Now users can set any of the pre-defined option field, and can also add their
|
||||
own fields!
|
||||
|
||||
```nix
|
||||
# in user's config
|
||||
{
|
||||
vim.your-plugin.setupOpts = {
|
||||
enable_feature_a = true;
|
||||
number_option = 4;
|
||||
another_field = "hello";
|
||||
size = { # nested fields work as well
|
||||
top = 10;
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Details of toLuaObject {#sec-details-of-toluaobject}
|
||||
|
||||
As you've seen above, `toLuaObject` is used to convert our nix attrSet
|
||||
`cfg.setupOpts`, into a lua table. Here are some rules of the conversion:
|
||||
|
||||
1. Nix `null` converts to lua `nil`
|
||||
2. Number and strings convert to their lua counterparts
|
||||
3. Nix attribute sets (`{}`) and lists (`[]`) convert into Lua dictionaries and
|
||||
tables respectively. Here is an example of Nix -> Lua conversion.
|
||||
- `{foo = "bar"}` -> `{["foo"] = "bar"}`
|
||||
- `["foo" "bar"]` -> `{"foo", "bar"}`
|
||||
4. You can write raw Lua code using `lib.generators.mkLuaInline`. This function
|
||||
is part of nixpkgs, and is accessible without relying on **nvf**'s extended
|
||||
library.
|
||||
- `mkLuaInline "function add(a, b) return a + b end"` will yield the
|
||||
following result:
|
||||
|
||||
```nix
|
||||
{
|
||||
_type = "lua-inline";
|
||||
expr = "function add(a, b) return a + b end";
|
||||
}
|
||||
```
|
||||
|
||||
The above expression will be interpreted as a Lua expression in the final
|
||||
config. Without the `mkLuaInline` function, you will only receive a string
|
||||
literal. You can use it to feed plugin configuration tables Lua functions
|
||||
that return specific values as expected by the plugins.
|
||||
|
||||
```nix
|
||||
{
|
||||
vim.your-plugin.setupOpts = {
|
||||
on_init = lib.generators.mkLuaInline ''
|
||||
function()
|
||||
print('we can write lua!')
|
||||
end
|
||||
'';
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Lazy plugins {#sec-lazy-plugins}
|
||||
|
||||
If the plugin can be lazy-loaded, `vim.lazy.plugins` should be used to add it.
|
||||
Lazy plugins are managed by `lz.n`.
|
||||
|
||||
```nix
|
||||
# in modules/.../your-plugin/config.nix
|
||||
{config, ...}: let
|
||||
cfg = config.vim.your-plugin;
|
||||
in {
|
||||
vim.lazy.plugins.your-plugin = {
|
||||
# Instead of vim.startPlugins, use this:
|
||||
package = "your-plugin";
|
||||
|
||||
# ıf your plugin uses the `require('your-plugin').setup{...}` pattern
|
||||
setupModule = "your-plugin";
|
||||
inherit (cfg) setupOpts;
|
||||
|
||||
# Events that trigger this plugin to be loaded
|
||||
event = ["DirChanged"];
|
||||
cmd = ["YourPluginCommand"];
|
||||
|
||||
# Plugin Keymaps
|
||||
keys = [
|
||||
# We'll cover this in detail in the 'keybinds' section
|
||||
{
|
||||
key = "<leader>d";
|
||||
mode = "n";
|
||||
action = ":YourPluginCommand";
|
||||
}
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
This results in the following lua code:
|
||||
|
||||
```lua
|
||||
require('lz.n').load({
|
||||
{
|
||||
"name-of-your-plugin",
|
||||
after = function()
|
||||
require('your-plugin').setup({
|
||||
--[[ your setupOpts ]]--
|
||||
})
|
||||
end,
|
||||
|
||||
event = {"DirChanged"},
|
||||
cmd = {"YourPluginCommand"},
|
||||
keys = {
|
||||
{"<leader>d", ":YourPluginCommand", mode = {"n"}},
|
||||
},
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
[`vim.lazy.plugins` spec]: https://notashelf.github.io/nvf/options.html#opt-vim.lazy.plugins
|
||||
|
||||
A full list of options can be found in the [`vim.lazy.plugins` spec] on the
|
||||
rendered manual.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Getting Started {#sec-contrib-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](https://help.github.com/articles/fork-a-repo/) for
|
||||
instructions on how you can do this. Once you have a fork of **nvf**, you should
|
||||
create a separate branch based on the 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](#sec-guidelines), push the branch to GitHub and
|
||||
[create a pull request](https://help.github.com/articles/creating-a-pull-request).
|
||||
The default pull request template available on the **nvf** repository will guide
|
||||
you through the rest of the process, and we'll gently nudge you in the correct
|
||||
direction if there are any mistakes.
|
||||
|
|
@ -1,188 +0,0 @@
|
|||
# Guidelines {#sec-guidelines}
|
||||
|
||||
If your contribution tightly follows the guidelines, then there is a good chance
|
||||
it will be merged without too much trouble. Some of the guidelines will be
|
||||
strictly enforced, others will remain as gentle nudges towards the correct
|
||||
direction. As we have no automated system enforcing those guidelines, please try
|
||||
to double check your changes before making your pull request in order to avoid
|
||||
"faulty" code slipping by.
|
||||
|
||||
If you are uncertain how these rules affect the change you would like to make
|
||||
then feel free to start a discussion in the
|
||||
[discussions tab](https://github.com/NotAShelf/nvf/discussions) ideally (but not
|
||||
necessarily) before you start developing.
|
||||
|
||||
## Adding Documentation {#sec-guidelines-documentation}
|
||||
|
||||
[Nixpkgs Flavoured Markdown]: https://github.com/NixOS/nixpkgs/blob/master/doc/README.md#syntax
|
||||
|
||||
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:
|
||||
|
||||
```console
|
||||
$ nix build .#docs-html
|
||||
$ xdg-open $PWD/result/share/doc/nvf/index.html
|
||||
```
|
||||
|
||||
## Formatting Code {#sec-guidelines-formatting}
|
||||
|
||||
Make sure your code is formatted as described in
|
||||
[code-style section](#sec-guidelines-code-style). To maintain consistency
|
||||
throughout the project you are encouraged to browse through existing code and
|
||||
adopt its style also in new code.
|
||||
|
||||
## Formatting Commits {#sec-guidelines-commit-message-style}
|
||||
|
||||
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a
|
||||
consistent commit message format as described in
|
||||
[commit style guidelines](#sec-guidelines-commit-style).
|
||||
|
||||
## Commit Style {#sec-guidelines-commit-style}
|
||||
|
||||
The commits in your pull request should be reasonably self-contained. Which
|
||||
means each and every commit in a pull request should make sense both on its own
|
||||
and in general context. That is, a second commit should not resolve an issue
|
||||
that is introduced in an earlier commit. In particular, you will be asked to
|
||||
amend any commit that introduces syntax errors or similar problems even if they
|
||||
are fixed in a later commit.
|
||||
|
||||
The commit messages should follow the
|
||||
[seven rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
|
||||
"Capitalize the subject line". We also ask you to include the affected code
|
||||
component or module in the first line. A commit message ideally, but not
|
||||
necessarily, follow the given template from home-manager's own documentation
|
||||
|
||||
```
|
||||
{component}: {description}
|
||||
|
||||
{long description}
|
||||
```
|
||||
|
||||
where `{component}` refers to the code component (or module) your change
|
||||
affects, `{description}` is a very brief description of your change, and
|
||||
`{long description}` is an optional clarifying description. As a rare exception,
|
||||
if there is no clear component, or your change affects many components, then the
|
||||
`{component}` part is optional. See
|
||||
[example commit message](#sec-guidelines-ex-commit-message) for a commit message
|
||||
that fulfills these requirements.
|
||||
|
||||
## Example Commit {#sec-guidelines-ex-commit-message}
|
||||
|
||||
The commit
|
||||
[69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
|
||||
in home-manager contains the following commit message.
|
||||
|
||||
```
|
||||
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 {#sec-guidelines-code-style}
|
||||
|
||||
### Treewide {#sec-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 {#sec-code-style-nix}
|
||||
|
||||
[alejandra]: https://github.com/kamadorueda/alejandra
|
||||
|
||||
**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:
|
||||
|
||||
```nix
|
||||
# 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.
|
||||
|
||||
```nix
|
||||
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.
|
||||
|
||||
```nix
|
||||
# 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...
|
||||
];
|
||||
```
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
# Keybinds {#sec-keybinds}
|
||||
|
||||
As of 0.4, there exists an API for writing your own keybinds and a couple of
|
||||
useful utility functions are available in the
|
||||
[extended standard library](https://github.com/NotAShelf/nvf/tree/main/lib). The
|
||||
following section contains a general overview to how you may utilize said
|
||||
functions.
|
||||
|
||||
## Custom Key Mappings Support for a Plugin {#sec-custom-key-mappings}
|
||||
|
||||
To set a mapping, you should define it in `vim.keymaps`.
|
||||
|
||||
An example, simple keybinding, can look like this:
|
||||
|
||||
```nix
|
||||
{
|
||||
vim.keymaps = [
|
||||
{
|
||||
key = "<leader>wq";
|
||||
mode = ["n"];
|
||||
action = ":wq<CR>";
|
||||
silent = true;
|
||||
desc = "Save file and quit";
|
||||
}
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
There are many settings available in the options. Please refer to the
|
||||
[documentation](https://notashelf.github.io/nvf/options.html#opt-vim.keymaps) to
|
||||
see a list of them.
|
||||
|
||||
**nvf** provides a helper function, so that you don't have to write the mapping
|
||||
attribute sets every time:
|
||||
|
||||
- `mkKeymap`, which mimics neovim's `vim.keymap.set` function
|
||||
|
||||
You can read the source code of some modules to see them in action, but the
|
||||
usage should look something like this:
|
||||
|
||||
```nix
|
||||
# plugindefinition.nix
|
||||
{lib, ...}: let
|
||||
inherit (lib.options) mkEnableOption;
|
||||
inherit (lib.nvim.binds) mkMappingOption;
|
||||
in {
|
||||
options.vim.plugin = {
|
||||
enable = mkEnableOption "Enable plugin";
|
||||
|
||||
# Mappings should always be inside an attrset called mappings
|
||||
mappings = {
|
||||
workspaceDiagnostics = mkMappingOption "Workspace diagnostics [trouble]" "<leader>lwd";
|
||||
documentDiagnostics = mkMappingOption "Document diagnostics [trouble]" "<leader>ld";
|
||||
lspReferences = mkMappingOption "LSP References [trouble]" "<leader>lr";
|
||||
quickfix = mkMappingOption "QuickFix [trouble]" "<leader>xq";
|
||||
locList = mkMappingOption "LOCList [trouble]" "<leader>xl";
|
||||
symbols = mkMappingOption "Symbols [trouble]" "<leader>xs";
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
```nix
|
||||
# config.nix
|
||||
{
|
||||
config,
|
||||
lib,
|
||||
options,
|
||||
...
|
||||
}: let
|
||||
inherit (lib.modules) mkIf;
|
||||
inherit (lib.nvim.binds) mkKeymap;
|
||||
|
||||
cfg = config.vim.plugin;
|
||||
|
||||
keys = cfg.mappings;
|
||||
inherit (options.vim.lsp.trouble) mappings;
|
||||
in {
|
||||
config = mkIf cfg.enable {
|
||||
vim.keymaps = [
|
||||
(mkKeymap "n" keys.workspaceDiagnostics "<cmd>Trouble toggle diagnostics<CR>" {desc = mappings.workspaceDiagnostics.description;})
|
||||
(mkKeymap "n" keys.documentDiagnostics "<cmd>Trouble toggle diagnostics filter.buf=0<CR>" {desc = mappings.documentDiagnostics.description;})
|
||||
(mkKeymap "n" keys.lspReferences "<cmd>Trouble toggle lsp_references<CR>" {desc = mappings.lspReferences.description;})
|
||||
(mkKeymap "n" keys.quickfix "<cmd>Trouble toggle quickfix<CR>" {desc = mappings.quickfix.description;})
|
||||
(mkKeymap "n" keys.locList "<cmd>Trouble toggle loclist<CR>" {desc = mappings.locList.description;})
|
||||
(mkKeymap "n" keys.symbols "<cmd>Trouble toggle symbols<CR>" {desc = mappings.symbols.description;})
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
|
||||
If you have come across a plugin that has an API that doesn't seem to easily
|
||||
allow custom keybindings, don't be scared to implement a draft PR. We'll help
|
||||
you get it done.
|
||||
|
||||
:::
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# Testing Changes {#sec-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.
|
||||
115
docs/manual/index.md
Normal file
115
docs/manual/index.md
Normal file
|
|
@ -0,0 +1,115 @@
|
|||
# Introduction {#nvf-manual}
|
||||
|
||||
Generated for nvf @NVF_VERSION@
|
||||
|
||||
## Preface {#ch-preface}
|
||||
|
||||
### What is nvf {#sec-what-is-it}
|
||||
|
||||
[Nix]: https://nixos.org
|
||||
|
||||
**nvf** is a highly modular, configurable, extensible and _easy to use_ Neovim
|
||||
configuration framework built for and designed to be used with [Nix]. Boasting
|
||||
flexibility, robustness and ease of use (among other positive traits), this
|
||||
project allows you to configure a fully featured Neovim instance with a few
|
||||
lines of Nix while leaving all kinds of doors open for integrating Lua in your
|
||||
configurations _whether you are a beginner or an advanced user_.
|
||||
|
||||
## Try it Out {#ch-try-it-out}
|
||||
|
||||
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** (`packages.nix`) - Nix language server + simple utility plugins
|
||||
- **Maximal** (`packages.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.
|
||||
|
||||
```sh
|
||||
# Add the nvf cache
|
||||
$ cachix use nvf # Optional: it'll save you CPU resources and time
|
||||
|
||||
# Run the minimal configuration with the cache enabled
|
||||
$ nix run github:notashelf/nvf#nix # Will run the default minimal configuration
|
||||
```
|
||||
|
||||
Do keep in mind that this is **susceptible to garbage collection** meaning that
|
||||
the built outputs will be removed from your Nix store once you garbage collect.
|
||||
|
||||
## Using Prebuilt Configurations {#sec-using-prebuilt-configs}
|
||||
|
||||
<!-- markdownlint-disable MD014 -->
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#nix
|
||||
$ nix run github:notashelf/nvf#maximal
|
||||
```
|
||||
|
||||
<!-- markdownlint-enable MD014 -->
|
||||
|
||||
### Available Configurations {#sec-available-configs}
|
||||
|
||||
> [!NOTE]
|
||||
> The below configurations are provided for demonstration purposes, and are
|
||||
> **not** designed to be installed as is. You may refer to the installation
|
||||
> steps below and the helpful tips section for details on creating your own
|
||||
> configurations.
|
||||
|
||||
#### Nix {#sec-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.
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#nix test.nix
|
||||
# => This will open a file called `test.nix` with Nix LSP and syntax highlighting
|
||||
```
|
||||
|
||||
This command will start Neovim with some opinionated plugin configurations, and
|
||||
is designed specifically for Nix. The `nix` configuration lets you see how a
|
||||
fully configured Neovim setup _might_ look like without downloading too many
|
||||
packages or shell utilities.
|
||||
|
||||
#### Maximal {#sec-configs-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.
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#maximal -- test.nix
|
||||
# => This will open a file called `test.nix` with a variety of plugins available
|
||||
```
|
||||
|
||||
It uses the same configuration template with the [Nix](#sec-configs-nix)
|
||||
configuration, but supports many more languages, and enables more utility,
|
||||
companion or fun plugins.
|
||||
|
||||
> [!WARNING]
|
||||
> Running the maximal config will download _a lot_ of packages as it is
|
||||
> downloading language servers, formatters, and more. If CPU time and bandwidth
|
||||
> are concerns, please use the default package instead.
|
||||
|
||||
## Installing nvf {#ch-installation}
|
||||
|
||||
<!-- markdownlint-disable MD051 -->
|
||||
|
||||
[module installation section]: #ch-module-installation
|
||||
|
||||
<!-- markdownlint-enable MD051 -->
|
||||
|
||||
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].
|
||||
|
||||
```{=include=}
|
||||
installation/custom-configuration.md
|
||||
installation/modules.md
|
||||
```
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
# Installing nvf {#ch-installation}
|
||||
|
||||
[module installation section]: #ch-module-installation
|
||||
|
||||
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].
|
||||
|
||||
```{=include=} chapters
|
||||
installation/custom-configuration.md
|
||||
installation/modules.md
|
||||
```
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
### Prerequisites {#sec-flakes-prerequisites}
|
||||
#### Prerequisites {#sec-flakes-prerequisites}
|
||||
|
||||
To install nvf with flakes, you must make sure the following requirements are
|
||||
met.
|
||||
To install **nvf** with flakes, you must make sure the following requirements
|
||||
are met.
|
||||
|
||||
1. Nix 2.4 or later must be installed. You may use `nix-shell` to get a later
|
||||
version of Nix from nixpkgs.
|
||||
|
|
@ -29,5 +29,6 @@ met.
|
|||
following additional flags to `nix` and `home-manager`:
|
||||
|
||||
```sh
|
||||
# Temporarily enables "nix-command" and "flakes" experimental features.
|
||||
$ nix --extra-experimental-features "nix-command flakes" <sub-commands>
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Home-Manager Module {#ch-hm-module}
|
||||
## Home Manager Module {#ch-hm-module}
|
||||
|
||||
The home-manager module allows us to customize the different `vim` options from
|
||||
inside the home-manager configuration without having to call for the wrapper
|
||||
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.
|
||||
|
||||
|
|
@ -19,20 +19,13 @@ To use **nvf** with flakes, we first need to add the input to our `flake.nix`.
|
|||
# flake.nix
|
||||
{
|
||||
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 works best with 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
|
||||
};
|
||||
|
||||
# ...
|
||||
|
|
@ -44,8 +37,8 @@ Followed by importing the home-manager module somewhere in your configuration.
|
|||
|
||||
```nix
|
||||
{
|
||||
# Assuming "nvf" is in your inputs and inputs is in the argument set.
|
||||
# See example installation below
|
||||
# Assuming nvf is in your inputs and inputs is in the argument set.
|
||||
# See example installation below.
|
||||
imports = [ inputs.nvf.homeManagerModules.default ];
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# NixOS Module {#ch-nixos-module}
|
||||
## NixOS Module {#ch-nixos-module}
|
||||
|
||||
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.
|
||||
|
||||
## With Flakes {#sec-nixos-flakes}
|
||||
### With Flakes {#sec-nixos-flakes}
|
||||
|
||||
```{=include=}
|
||||
flakes.md
|
||||
|
|
@ -19,20 +19,13 @@ To use **nvf** with flakes, we first need to add the input to our `flake.nix`.
|
|||
# flake.nix
|
||||
{
|
||||
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 works best with 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
|
||||
};
|
||||
|
||||
# ...
|
||||
|
|
@ -44,8 +37,8 @@ Followed by importing the NixOS module somewhere in your configuration.
|
|||
|
||||
```nix
|
||||
{
|
||||
# assuming nvf is in your inputs and inputs is in the argset
|
||||
# see example below
|
||||
# Assuming nvf is in your inputs and inputs is in the argument set.
|
||||
# See example below.
|
||||
imports = [ inputs.nvf.nixosModules.default ];
|
||||
}
|
||||
```
|
||||
|
|
@ -79,7 +72,6 @@ configure **nvf**.
|
|||
{
|
||||
programs.nvf = {
|
||||
enable = true;
|
||||
|
||||
# Your settings need to go into the settings attribute set
|
||||
# most settings are documented in the appendix
|
||||
settings = {
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Standalone Installation on Home-Manager {#ch-standalone-hm}
|
||||
## Standalone Installation on Home-Manager {#ch-standalone-hm}
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Standalone Installation on NixOS {#ch-standalone-nixos}
|
||||
## Standalone Installation on NixOS {#ch-standalone-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
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
# nvf manual {#nvf-manual}
|
||||
|
||||
## Version @NVF_VERSION@
|
||||
|
||||
```{=include=} preface
|
||||
preface.md
|
||||
try-it-out.md
|
||||
```
|
||||
|
||||
```{=include=} parts
|
||||
installation.md
|
||||
configuring.md
|
||||
tips.md
|
||||
```
|
||||
|
||||
```{=include=} chapters
|
||||
hacking.md
|
||||
```
|
||||
|
||||
```{=include=} appendix html:into-file=//quirks.html
|
||||
quirks.md
|
||||
```
|
||||
|
||||
```{=include=} appendix html:into-file=//options.html
|
||||
options.md
|
||||
```
|
||||
|
||||
```{=include=} appendix html:into-file=//release-notes.html
|
||||
release-notes/release-notes.md
|
||||
```
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# nvf Configuration Options {#ch-options}
|
||||
|
||||
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 let us know if you believe any of
|
||||
the options below are missing useful examples.
|
||||
|
||||
<!--
|
||||
In the manual, individual options may be referenced in Hyperlinks as follows:
|
||||
[](#opt-vim.*) If changing the prefix here, do keep in mind the #opt- suffix will have
|
||||
to be changed everywhere.
|
||||
-->
|
||||
|
||||
```{=include=} options
|
||||
id-prefix: opt-
|
||||
list-id: nvf-options
|
||||
source: @OPTIONS_JSON@
|
||||
```
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# Preface {#ch-preface}
|
||||
|
||||
## What is nvf {#sec-what-is-it}
|
||||
|
||||
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 {#sec-bugs-suggestions}
|
||||
|
||||
[issue tracker]: https://github.com/notashelf/nvf/issues
|
||||
[discussions tab]: https://github.com/notashelf/nvf/discussions
|
||||
[pull requests tab]: https://github.com/notashelf/nvf/pulls
|
||||
|
||||
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].
|
||||
|
|
@ -5,9 +5,20 @@ 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.
|
||||
|
||||
<!-- If adding a new known quirk, please create a new page in quirks/ and include
|
||||
the name of the file here.-->
|
||||
|
||||
```{=include=} chapters
|
||||
```{=include=}
|
||||
quirks/nodejs.md
|
||||
```
|
||||
|
||||
## Bugs & Suggestions {#ch-bugs-suggestions}
|
||||
|
||||
[issue tracker]: https://github.com/notashelf/nvf/issues
|
||||
[discussions tab]: https://github.com/notashelf/nvf/discussions
|
||||
[pull requests tab]: https://github.com/notashelf/nvf/pulls
|
||||
|
||||
Some quirks are not exactly quirks, but bugs in the module system. 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 bug fixes, feature additions and upstreamed
|
||||
changes that you think are critical over at the [pull requests tab].
|
||||
|
|
|
|||
|
|
@ -1,24 +1,29 @@
|
|||
# NodeJS {#ch-quirks-nodejs}
|
||||
## NodeJS {#ch-quirks-nodejs}
|
||||
|
||||
## eslint-plugin-prettier {#sec-eslint-plugin-prettier}
|
||||
### eslint-plugin-prettier {#sec-eslint-plugin-prettier}
|
||||
|
||||
When working with NodeJS, everything works as expected, but some projects have
|
||||
settings that can fool nvf.
|
||||
[eslint-plugin-prettier]: https://github.com/prettier/eslint-plugin-prettier
|
||||
[not supposed to]: https://prettier.io/docs/en/comparison.html
|
||||
|
||||
If [this plugin](https://github.com/prettier/eslint-plugin-prettier) or similar
|
||||
is included, you might get a situation where your eslint configuration diagnoses
|
||||
your formatting according to its own config (usually `.eslintrc.js`).
|
||||
When working with NodeJS, which is _obviously_ known for its meticulous
|
||||
standards, most things are bound to work as expected but some projects, tools
|
||||
and settings may fool the default configurations of tools provided by **nvf**.
|
||||
|
||||
The issue there is your formatting is made via prettierd.
|
||||
If
|
||||
|
||||
This results in auto-formatting relying on your prettier config, while your
|
||||
eslint config diagnoses formatting
|
||||
[which it's not supposed to](https://prettier.io/docs/en/comparison.html))
|
||||
If [eslint-plugin-prettier] 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.
|
||||
|
||||
In the end, you get discrepancies between what your editor does and what it
|
||||
wants.
|
||||
This results in auto-formatting relying on your prettier configuration, while
|
||||
your Eslint configuration diagnoses formatting "issues" while it's
|
||||
[not supposed to]. In the end, you get discrepancies between what your editor
|
||||
does and what it wants.
|
||||
|
||||
Solutions are:
|
||||
|
||||
1. Don't add a formatting config to eslint, and separate prettier and eslint.
|
||||
2. PR this repo to add an ESLint formatter and configure nvf to use it.
|
||||
1. Don't add a formatting config to Eslint, instead separate Prettier and
|
||||
Eslint.
|
||||
2. PR the repo in question to add an ESLint formatter, and configure **nvf** to
|
||||
use it.
|
||||
|
|
|
|||
16
docs/manual/release-notes.md
Normal file
16
docs/manual/release-notes.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
# Release Notes {#ch-release-notes}
|
||||
|
||||
This section lists the release notes for tagged version of **nvf** and the
|
||||
current main current main branch
|
||||
|
||||
```{=include=} chapters
|
||||
release-notes/rl-0.1.md
|
||||
release-notes/rl-0.2.md
|
||||
release-notes/rl-0.3.md
|
||||
release-notes/rl-0.4.md
|
||||
release-notes/rl-0.5.md
|
||||
release-notes/rl-0.6.md
|
||||
release-notes/rl-0.7.md
|
||||
release-notes/rl-0.8.md
|
||||
release-notes/rl-0.9.md
|
||||
```
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.1 {#sec-release-0.1}
|
||||
# Release 0.1 {#sec-release-0-1}
|
||||
|
||||
This is the current master branch and information here is not final. These are
|
||||
changes from the v0.1 tag.
|
||||
|
|
@ -7,7 +7,7 @@ Special thanks to [home-manager](https://github.com/nix-community/home-manager/)
|
|||
for this release. Docs/manual generation, the new module evaluation system, and
|
||||
DAG implementation are from them.
|
||||
|
||||
## Changelog {#sec-release-0.1-changelog}
|
||||
## Changelog {#sec-release-0-1-changelog}
|
||||
|
||||
[jordanisaacs](https://github.com/jordanisaacs):
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ DAG implementation are from them.
|
|||
longer defined. If you use hare and would like it added back, please file an
|
||||
issue.
|
||||
|
||||
- [](#opt-vim.startPlugins) & [](#opt-vim.optPlugins) are now an enum of
|
||||
- {option}`vim.startPlugins` & {option} `vim-optPlugins` are now an enum of
|
||||
`string` for options sourced from the flake inputs. Users can still provide
|
||||
vim plugin packages.
|
||||
|
||||
|
|
@ -28,13 +28,13 @@ DAG implementation are from them.
|
|||
[relevant discourse post]: https://discourse.nixos.org/t/psa-if-you-are-on-unstable-try-out-nvim-treesitter-withallgrammars/23321?u=snowytrees
|
||||
|
||||
- Treesitter grammars are now configurable with
|
||||
[](#opt-vim.treesitter.grammars). Utilizes the nixpkgs `nvim-treesitter`
|
||||
{option}`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 [](#opt-vim.luaConfigRC) are now of type DAG lines. This
|
||||
- `vim.configRC` and {option}`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.
|
||||
|
||||
|
|
@ -44,5 +44,6 @@ vim.luaConfigRC = lib.nvim.dag.entryAnywhere "config here"
|
|||
|
||||
[MoritzBoehme](https://github.com/MoritzBoehme):
|
||||
|
||||
- `catppuccin` theme is now available as a neovim theme [](#opt-vim.theme.style)
|
||||
and Lualine theme [](#opt-vim.statusline.lualine.theme).
|
||||
- `catppuccin` theme is now available as a neovim theme
|
||||
{option}`vim.theme.style` and Lualine theme
|
||||
{option}`vim.statusline.lualine.theme`.
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
# Release 0.2 {#sec-release-0.2}
|
||||
# Release 0.2 {#sec-release-0-2}
|
||||
|
||||
Release notes for release 0.2
|
||||
|
||||
## Changelog {#sec-release-0.2-changelog}
|
||||
## Changelog {#sec-release-0-2-changelog}
|
||||
|
||||
[notashelf](https://github.com/notashelf):
|
||||
|
||||
|
|
@ -10,55 +10,39 @@ Release notes for release 0.2
|
|||
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.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.3 {#sec-release-0.3}
|
||||
# Release 0.3 {#sec-release-0-3}
|
||||
|
||||
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,
|
||||
|
|
@ -7,7 +7,7 @@ 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 {#sec-release-0.3-changelog}
|
||||
## Changelog {#sec-release-0-3-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
|
||||
|
|
@ -39,7 +39,7 @@ soon.
|
|||
[discourse]: https://discourse.nixos.org/t/psa-if-you-are-on-unstable-try-out-nvim-treesitter-withallgrammars/23321?u=snowytrees
|
||||
|
||||
- Treesitter grammars are now configurable with
|
||||
[](#opt-vim.treesitter.grammars). Utilizes the nixpkgs `nvim-treesitter`
|
||||
{option}`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.
|
||||
|
|
@ -50,20 +50,20 @@ soon.
|
|||
|
||||
- A new section has been added for language support: `vim.languages.<language>`.
|
||||
|
||||
- The options `enableLSP` [](#opt-vim.languages.enableTreesitter), etc. will
|
||||
- The options `enableLSP` {option}`vim.languages.enableTreesitter`, etc. will
|
||||
enable the respective section for all languages that have been enabled.
|
||||
- All LSP languages have been moved here
|
||||
- `plantuml` and `markdown` have been moved here
|
||||
- A new section has been added for `html`. The old
|
||||
`vim.treesitter.autotagHtml` can be found at
|
||||
[](#opt-vim.languages.html.treesitter.autotagHtml).
|
||||
{option}`vim.languages.html.treesitter.autotagHtml`.
|
||||
|
||||
- `vim.git.gitsigns.codeActions` has been added, allowing you to turn on
|
||||
Gitsigns' code actions.
|
||||
|
||||
- Removed the plugins document in the docs. Was too unwieldy to keep updated.
|
||||
|
||||
- `vim.visual.lspkind` has been moved to [](#opt-vim.lsp.lspkind.enable)
|
||||
- `vim.visual.lspkind` has been moved to {option}`vim.lsp.lspkind.enable`
|
||||
|
||||
- Improved handling of completion formatting. When setting
|
||||
`vim.autocomplete.sources`, can also include optional menu mapping. And can
|
||||
|
|
@ -74,7 +74,7 @@ soon.
|
|||
by using `null` rather than `""` now.
|
||||
|
||||
- Transparency has been made optional and has been disabled by default.
|
||||
[](#opt-vim.theme.transparent) option can be used to enable or disable
|
||||
{option}`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
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.4 {#sec-release-0.4}
|
||||
# Release 0.4 {#sec-release-0-4}
|
||||
|
||||
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
|
||||
|
|
@ -12,7 +12,7 @@ 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.
|
||||
|
||||
## Changelog {#sec-release-0.4-changelog}
|
||||
## Changelog {#sec-release-0-4-changelog}
|
||||
|
||||
[n3oney](https://github.com/n3oney):
|
||||
|
||||
|
|
@ -1,8 +1,6 @@
|
|||
# Release 0.5 {#sec-release-0.5}
|
||||
# Release 0.5 {#sec-release-0-5}
|
||||
|
||||
Release notes for release 0.5
|
||||
|
||||
## Changelog {#sec-release-0.5-changelog}
|
||||
## Changelog {#sec-release-0-5-changelog}
|
||||
|
||||
[vagahbond](https://github.com/vagahbond):
|
||||
|
||||
|
|
@ -17,14 +15,14 @@ Release notes for release 0.5
|
|||
- Fixed a bug where cmp's close and scrollDocs mappings wasn't working
|
||||
|
||||
- Streamlined and simplified extra plugin API with the addition of
|
||||
[](#opt-vim.extraPlugins)
|
||||
{option}`vim.extraPlugins`
|
||||
|
||||
- Allow using command names in place of LSP packages to avoid automatic
|
||||
installation
|
||||
|
||||
- Add lua LSP and Treesitter support, and neodev.nvim plugin support
|
||||
|
||||
- Add [](#opt-vim.lsp.mappings.toggleFormatOnSave) keybind
|
||||
- Add {option}`vim.lsp.mappings.toggleFormatOnSave` keybind
|
||||
|
||||
[amanse](https://github.com/amanse):
|
||||
|
||||
|
|
@ -52,10 +50,10 @@ Release notes for release 0.5
|
|||
|
||||
- Added GitHub Copilot to nvim-cmp completion sources.
|
||||
|
||||
- Added [](#opt-vim.ui.borders.enable) for global and individual plugin border
|
||||
- Added {option}`vim.ui.borders.enable` for global and individual plugin border
|
||||
configuration.
|
||||
|
||||
- LSP integrated breadcrumbs with [](#opt-vim.ui.breadcrumbs.enable) through
|
||||
- LSP integrated breadcrumbs with {option}`vim.ui.breadcrumbs.enable` through
|
||||
nvim-navic
|
||||
|
||||
- LSP navigation helper with nvim-navbuddy, depends on nvim-navic (automatically
|
||||
|
|
@ -66,14 +64,14 @@ Release notes for release 0.5
|
|||
- Fixed mismatching Zig language description
|
||||
|
||||
- Added support for `statix` and `deadnix` through
|
||||
[](#opt-vim.languages.nix.extraDiagnostics.types)
|
||||
{option}`vim.languages.nix.extraDiagnostics.types`
|
||||
|
||||
- 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
|
||||
[](#opt-vim.package). For best results, always use an unwrapped package
|
||||
{option}`vim.package`. For best results, always use an unwrapped package
|
||||
|
||||
- Added highlight-undo plugin for highlighting undo/redo targets
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.6 {#sec-release-0.6}
|
||||
# Release 0.6 {#sec-release-0-6}
|
||||
|
||||
Release notes for release 0.6
|
||||
|
||||
|
|
@ -41,14 +41,14 @@ end
|
|||
vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap = true, silent = true })
|
||||
```
|
||||
|
||||
## Changelog {#sec-release-0.6-changelog}
|
||||
## Changelog {#sec-release-0-6-changelog}
|
||||
|
||||
[ksonj](https://github.com/ksonj):
|
||||
|
||||
- Added Terraform language support.
|
||||
|
||||
- Added `ChatGPT.nvim`, which can be enabled with
|
||||
[](#opt-vim.assistant.chatgpt.enable). Do keep in mind that this option
|
||||
{option}`vim.assistant.chatgpt.enable`. Do keep in mind that this option
|
||||
requires `OPENAI_API_KEY` environment variable to be set.
|
||||
|
||||
[donnerinoern](https://github.com/donnerinoern):
|
||||
|
|
@ -95,7 +95,7 @@ vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap =
|
|||
and also has been removed.
|
||||
|
||||
- `which-key.nvim` categories can now be customized through
|
||||
[vim.binds.whichKey.register](#opt-vim.binds.whichKey.register)
|
||||
[vim.binds.whichKey.register](./options.html#option-vim-binds-whichKey-register)
|
||||
|
||||
- Added `magick` to `vim.luaPackages` for `image.nvim`.
|
||||
|
||||
|
|
@ -125,10 +125,10 @@ vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap =
|
|||
|
||||
- Lualine module now allows customizing `always_divide_middle`, `ignore_focus`
|
||||
and `disabled_filetypes` through the new options:
|
||||
[vim.statusline.lualine.alwaysDivideMiddle](#opt-vim.statusline.lualine.alwaysDivideMiddle),
|
||||
[vim.statusline.lualine.ignoreFocus](#opt-vim.statusline.lualine.ignoreFocus)
|
||||
[vim.statusline.lualine.alwaysDivideMiddle](./options.html#option-vim-statusline-lualine-alwaysDivideMiddle),
|
||||
[vim.statusline.lualine.ignoreFocus](./options.html#option-vim-statusline-lualine-ignoreFocus)
|
||||
and
|
||||
[vim.statusline.lualine.disabledFiletypes](#opt-vim.statusline.lualine.disabledFiletypes).
|
||||
[vim.statusline.lualine.disabledFiletypes](./options.html#option-vim-statusline-lualine-disabledFiletypes).
|
||||
|
||||
- Updated all plugin inputs to their latest versions (**21.04.2024**) - this
|
||||
brought minor color changes to the Catppuccin theme.
|
||||
|
|
@ -159,10 +159,10 @@ vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap =
|
|||
arguments to take `luaBefore`, `luaConfig` and `luaAfter` as strings, which
|
||||
are then concatted inside a lua block.
|
||||
|
||||
- Added [](#opt-vim.luaConfigPre) and [](#opt-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 {option}`vim.luaConfigPre` and {option} `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
|
||||
|
|
@ -172,12 +172,12 @@ vim.api.nvim_set_keymap('n', '<leader>a', ':lua camelToSnake()<CR>', { noremap =
|
|||
- Exposed `withRuby`, `withNodeJs`, `withPython3`, and `python3Packages` from
|
||||
the `makeNeovimConfig` function under their respective options.
|
||||
|
||||
- Added [](#opt-vim.extraPackages) for appending additional packages to the
|
||||
- Added {option}`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 [](#opt-vim.notify.nvim-notify.setupOpts.render) which takes either a
|
||||
- Added {option}`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.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.7 {#sec-release-0.7}
|
||||
# Release 0.7 {#sec-release-0-7}
|
||||
|
||||
Release notes for release 0.7
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ options that were under `vim` as convenient shorthands for `vim.o.*` options.
|
|||
|
||||
::: {.warning}
|
||||
|
||||
As v0.7 features the addition of [](#opt-vim.options), those options are now
|
||||
As v0.7 features the addition of {option}`vim.options`, those options are now
|
||||
considered as deprecated. You should migrate to the appropriate options in the
|
||||
`vim.options` submodule.
|
||||
|
||||
|
|
@ -108,14 +108,14 @@ The changes are, in no particular order:
|
|||
|
||||
- `colourTerm`, `mouseSupport`, `cmdHeight`, `updateTime`, `mapTime`,
|
||||
`cursorlineOpt`, `splitBelow`, `splitRight`, `autoIndent` and `wordWrap` have
|
||||
been mapped to their [](#opt-vim.options) equivalents. Please see the module
|
||||
been mapped to their {option}`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.
|
||||
|
||||
## Changelog {#sec-release-0.7-changelog}
|
||||
## Changelog {#sec-release-0-7-changelog}
|
||||
|
||||
[ItsSorae](https://github.com/ItsSorae):
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ The changes are, in no particular order:
|
|||
[frothymarrow](https://github.com/frothymarrow):
|
||||
|
||||
- Modified type for
|
||||
[](#opt-vim.visuals.fidget-nvim.setupOpts.progress.display.overrides) from
|
||||
{option}`vim.visuals.fidget-nvim.setupOpts.progress.display.overrides` from
|
||||
`anything` to a `submodule` for better type checking.
|
||||
|
||||
- Fix null `vim.lsp.mappings` generating an error and not being filtered out.
|
||||
|
|
@ -134,7 +134,7 @@ The changes are, in no particular order:
|
|||
group for `Normal`, `NormalFloat`, `LineNr`, `SignColumn` and optionally
|
||||
`NvimTreeNormal` to `none`.
|
||||
|
||||
- Fix [](#opt-vim.ui.smartcolumn.setupOpts.custom_colorcolumn) using the wrong
|
||||
- Fix {option}`vim.ui.smartcolumn.setupOpts.custom_colorcolumn` using the wrong
|
||||
type `int` instead of the expected type `string`.
|
||||
|
||||
[horriblename](https://github.com/horriblename):
|
||||
|
|
@ -170,7 +170,7 @@ The changes are, in no particular order:
|
|||
|
||||
- Add [ocaml-lsp] support
|
||||
|
||||
- Fix misspelled "Emacs"
|
||||
- Fix "Emac" typo
|
||||
|
||||
- Add [new-file-template.nvim] to automatically fill new file contents using
|
||||
templates
|
||||
|
|
@ -216,18 +216,18 @@ The changes are, in no particular order:
|
|||
|
||||
- Remove `autopairs.type`, and rename `autopairs.enable` to
|
||||
`autopairs.nvim-autopairs.enable`. The new
|
||||
[](#opt-vim.autopairs.nvim-autopairs.enable) supports `setupOpts` format by
|
||||
{option}`vim.autopairs.nvim-autopairs.enable` supports `setupOpts` format by
|
||||
default.
|
||||
|
||||
- Refactor of `nvim-cmp` and completion related modules
|
||||
|
||||
- Remove `autocomplete.type` in favor of per-plugin enable options such as
|
||||
[](#opt-vim.autocomplete.nvim-cmp.enable).
|
||||
{option}`vim.autocomplete.nvim-cmp.enable`.
|
||||
- Deprecate legacy Vimsnip in favor of Luasnip, and integrate
|
||||
friendly-snippets for bundled snippets. [](#opt-vim.snippets.luasnip.enable)
|
||||
can be used to toggle Luasnip.
|
||||
friendly-snippets for bundled snippets.
|
||||
{option}`vim.snippets.luasnip.enable` can be used to toggle Luasnip.
|
||||
- Add sorting function options for completion sources under
|
||||
[](#opt-vim.autocomplete.nvim-cmp.setupOpts.sorting.comparators)
|
||||
{option}`vim.autocomplete.nvim-cmp.setupOpts.sorting.comparators`
|
||||
|
||||
- Add C# support under `vim.languages.csharp`, with support for both
|
||||
omnisharp-roslyn and csharp-language-server.
|
||||
|
|
@ -297,12 +297,12 @@ The changes are, in no particular order:
|
|||
Lualine. Only `vim.ui.breadcrumbs.lualine.winbar` is supported for the time
|
||||
being.
|
||||
|
||||
- [](#opt-vim.ui.breadcrumbs.lualine.winbar.enable) has been added to allow
|
||||
- {option}`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.
|
||||
- `vim.ui.breadcrumbs.alwaysRender` has been renamed to
|
||||
[](#opt-vim.ui.breadcrumbs.lualine.winbar.alwaysRender) to be conform to the
|
||||
new format.
|
||||
{option}`vim.ui.breadcrumbs.lualine.winbar.alwaysRender` to be conform to
|
||||
the new format.
|
||||
|
||||
- Add [basedpyright](https://github.com/detachhead/basedpyright) as a Python LSP
|
||||
server and make it default.
|
||||
|
|
@ -310,10 +310,10 @@ The changes are, in no particular order:
|
|||
- Add [python-lsp-server](https://github.com/python-lsp/python-lsp-server) as an
|
||||
additional Python LSP server.
|
||||
|
||||
- Add [](#opt-vim.options) to set `vim.o` values in in your nvf configuration
|
||||
- Add {option}`vim.options` to set `vim.o` values in in your nvf configuration
|
||||
without using additional Lua. See option documentation for more details.
|
||||
|
||||
- Add [](#opt-vim.dashboard.dashboard-nvim.setupOpts) to allow user
|
||||
- Add {option}`vim.dashboard.dashboard-nvim.setupOpts` to allow user
|
||||
configuration for [dashboard.nvim](https://github.com/nvimdev/dashboard-nvim)
|
||||
|
||||
- Update `lualine.nvim` input and add missing themes:
|
||||
|
|
@ -321,7 +321,7 @@ The changes are, in no particular order:
|
|||
- Adds `ayu`, `gruvbox_dark`, `iceberg`, `moonfly`, `onedark`,
|
||||
`powerline_dark` and `solarized_light` themes.
|
||||
|
||||
- Add [](#opt-vim.spellcheck.extraSpellWords) to allow adding arbitrary
|
||||
- Add {option}`vim.spellcheck.extraSpellWords` to allow adding arbitrary
|
||||
spellfiles to Neovim's runtime with ease.
|
||||
|
||||
- Add combined nvf configuration (`config.vim`) into the final package's
|
||||
|
|
@ -375,9 +375,9 @@ The changes are, in no particular order:
|
|||
[nezia1](https://github.com/nezia1):
|
||||
|
||||
- Add [biome](https://github.com/biomejs/biome) support for Typescript, CSS and
|
||||
Svelte. Enable them via [](#opt-vim.languages.ts.format.type),
|
||||
[](#opt-vim.languages.css.format.type) and
|
||||
[](#opt-vim.languages.svelte.format.type) respectively.
|
||||
Svelte. Enable them via {option}`vim.languages.ts.format.type`,
|
||||
{option}`vim.languages.css.format.type` and
|
||||
{option}`vim.languages.svelte.format.type` respectively.
|
||||
- Replace [nixpkgs-fmt](https://github.com/nix-community/nixpkgs-fmt) with
|
||||
[nixfmt](https://github.com/NixOS/nixfmt) (nixfmt-rfc-style).
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Release 0.8 {#sec-release-0.8}
|
||||
# Release 0.8 {#sec-release-0-8}
|
||||
|
||||
## Breaking changes
|
||||
|
||||
|
|
@ -21,13 +21,19 @@
|
|||
|
||||
- `vim.useSystemClipboard` has been deprecated as a part of removing most
|
||||
top-level convenience options, and should instead be configured in the new
|
||||
module interface. You may set [](#opt-vim.clipboard.registers) appropriately
|
||||
module interface. You may set {option}`vim.clipboard.registers` appropriately
|
||||
to configure Neovim to use the system clipboard.
|
||||
|
||||
- Changed which-key group used for gitsigns from `<leader>g` to `<leader>h` to
|
||||
align with the "hunks" themed mapping and avoid conflict with the new [neogit]
|
||||
group.
|
||||
|
||||
- LSP keybinds and related plugin integrations are now attached in an LspAttach
|
||||
autocmd event. If you were calling `default_on_attach()` in your LSP setup you
|
||||
can remove them now.
|
||||
|
||||
## Changelog {#sec-release-0-8-changelog}
|
||||
|
||||
[NotAShelf](https://github.com/notashelf):
|
||||
|
||||
[typst-preview.nvim]: https://github.com/chomosuke/typst-preview.nvim
|
||||
|
|
@ -48,16 +54,16 @@
|
|||
- Add [render-markdown.nvim] under
|
||||
`languages.markdown.extensions.render-markdown-nvim`.
|
||||
|
||||
- Implement [](#opt-vim.git.gitsigns.setupOpts) for user-specified setup table
|
||||
- Implement {option}`vim.git.gitsigns.setupOpts` for user-specified setup table
|
||||
in gitsigns configuration.
|
||||
|
||||
- [](#opt-vim.options.mouse) no longer compares values to an enum of available
|
||||
- {option}`vim.options.mouse` no longer compares values to an enum of available
|
||||
mouse modes. This means you can provide any string without the module system
|
||||
warning you that it is invalid. Do keep in mind that this value is no longer
|
||||
checked, so you will be responsible for ensuring its validity.
|
||||
|
||||
- Deprecate `vim.enableEditorconfig` in favor of
|
||||
[](#opt-vim.globals.editorconfig).
|
||||
{option}`vim.globals.editorconfig`.
|
||||
|
||||
- Deprecate rnix-lsp as it has been abandoned and archived upstream.
|
||||
|
||||
|
|
@ -66,10 +72,9 @@
|
|||
your Editorconfig configuration, or use an autocommand to set indentation
|
||||
values for buffers with the Nix filetype.
|
||||
|
||||
- Add [](#opt-vim.lsp.lightbulb.autocmd.enable) for manually managing the
|
||||
- Add {option}`vim.lsp.lightbulb.autocmd.enable` for manually managing the
|
||||
previously managed lightbulb autocommand.
|
||||
|
||||
- A warning will occur if [](#opt-vim.lsp.lightbulb.autocmd.enable) and
|
||||
- A warning will occur if {option} vim-lsp-lightbulb-autocmd-enable) and
|
||||
`vim.lsp.lightbulb.setupOpts.autocmd.enabled` are both set at the same time.
|
||||
Pick only one.
|
||||
|
||||
|
|
@ -80,7 +85,7 @@
|
|||
|
||||
- Add [yazi.nvim] as a companion plugin for Yazi, the terminal file manager.
|
||||
|
||||
- Add [](#opt-vim.autocmds) and [](#opt-vim.augroups) to allow declaring
|
||||
- Add {option}`vim.autocmds` and {option}`vim-augroups` to allow declaring
|
||||
autocommands via Nix.
|
||||
|
||||
- Fix plugin `setupOpts` for yanky.nvim and assert if shada is configured as a
|
||||
|
|
@ -102,7 +107,7 @@
|
|||
`vim.utility.oil-nvim`.
|
||||
- Add `vim.diagnostics` to interact with Neovim's diagnostics module. Available
|
||||
options for `vim.diagnostic.config()` can now be customized through the
|
||||
[](#opt-vim.diagnostics.config) in nvf.
|
||||
{option}`vim.diagnostics.config` in nvf.
|
||||
|
||||
- Add `vim.clipboard` module for easily managing Neovim clipboard providers and
|
||||
relevant packages in a simple UI.
|
||||
|
|
@ -111,6 +116,14 @@
|
|||
- Add [hunk.nvim], Neovim plugin & tool for splitting diffs in Neovim. Available
|
||||
as `vim.git.hunk-nvim`
|
||||
|
||||
- Move `crates.nvim` into `languages.rust.extensions and support` `setupOpts`
|
||||
for the plugin. Deprecates the top level "crates" option in `languages.rust`.
|
||||
|
||||
[sjcobb2022](https://github.com/sjcobb2022):
|
||||
|
||||
- Migrate all current lsp configurations to `vim.lsp.server` and remove internal
|
||||
dependency on `nvim-lspconfig`
|
||||
|
||||
[amadaluzia](https://github.com/amadaluzia):
|
||||
|
||||
[haskell-tools.nvim]: https://github.com/MrcJkb/haskell-tools.nvim
|
||||
|
|
@ -130,6 +143,11 @@
|
|||
- Moved code setting `additionalRuntimePaths` and `enableLuaLoader` out of
|
||||
`luaConfigPre`'s default to prevent being overridden
|
||||
- Use conform over custom autocmds for LSP format on save
|
||||
- Move LSP keybinds and other related plugin integrations into an LspAttach
|
||||
event.
|
||||
- Allow multiple formatters in language modules.
|
||||
- Fixed `prettier` in astro and svelte, and removed `prettierd` due to high
|
||||
complexity that would be needed to support it.
|
||||
|
||||
[diniamo](https://github.com/diniamo):
|
||||
|
||||
|
|
@ -191,7 +209,7 @@
|
|||
- Add [fzf-lua](https://github.com/ibhagwan/fzf-lua) in `vim.fzf-lua`
|
||||
- Add [rainbow-delimiters](https://github.com/HiPhish/rainbow-delimiters.nvim)
|
||||
in `vim.visuals.rainbow-delimiters`
|
||||
- Add options to define highlights under [](#opt-vim.highlight)
|
||||
- Add options to define highlights under {option}`vim.highlight`
|
||||
|
||||
[kaktu5](https://github.com/kaktu5):
|
||||
|
||||
|
|
@ -207,8 +225,8 @@
|
|||
|
||||
[thamenato](https://github.com/thamenato):
|
||||
|
||||
[ruff]: (https://github.com/astral-sh/ruff)
|
||||
[cue]: (https://cuelang.org/)
|
||||
[ruff]: https://github.com/astral-sh/ruff
|
||||
[cue]: https://cuelang.org/
|
||||
|
||||
- Add [ruff] as a formatter option in `vim.languages.python.format.type`.
|
||||
- Add [cue] support under `vim.languages.cue`.
|
||||
|
|
@ -284,6 +302,13 @@
|
|||
- Fix [blink.cmp] breaking when built-in sources were modified.
|
||||
- Fix [conform.nvim] not allowing disabling formatting on and after save. Use
|
||||
`null` value to disable them if conform is enabled.
|
||||
- Add [markdown-oxide](https://github.com/Feel-ix-343/markdown-oxide) option to
|
||||
markdown language module.
|
||||
- Fix Helm-YAML language module integration. YAML diagnostics will now remain in
|
||||
`helmfile`s when both are enabled.
|
||||
- Fix YAML language module not activating LSP keybinds if the Helm language
|
||||
module was also enabled.
|
||||
- Fix `json` language module (default) language server not activating.
|
||||
|
||||
[TheColorman](https://github.com/TheColorman):
|
||||
|
||||
|
|
@ -319,6 +344,7 @@
|
|||
- Add global function `nvf_lint` under
|
||||
`vim.diagnostics.nvim-lint.lint_function`.
|
||||
- Deprecate `vim.scrollOffset` in favor of `vim.options.scrolloff`.
|
||||
- Fix `svelte-language-server` not reloading .js/.ts files on change.
|
||||
|
||||
[Sc3l3t0n](https://github.com/Sc3l3t0n):
|
||||
|
||||
|
|
@ -381,7 +407,7 @@
|
|||
|
||||
[aionoid](https://github.com/aionoid):
|
||||
|
||||
[avante-nvim]: https://github.com/yetone/avante.nvim
|
||||
[avante.nvim]: https://github.com/yetone/avante.nvim
|
||||
|
||||
- Fix [render-markdown.nvim] file_types option type to list, to accept merging.
|
||||
- Add [avante.nvim] plugin under `vim.assistant.avante-nvim`.
|
||||
|
|
@ -389,9 +415,12 @@
|
|||
[poz](https://poz.pet):
|
||||
|
||||
[everforest]: https://github.com/sainnhe/everforest
|
||||
[oil]: https://github.com/stevearc/oil.nvim
|
||||
[oil-git-status]: https://github.com/refractalize/oil-git-status.nvim
|
||||
|
||||
- Fix gitsigns null-ls issue.
|
||||
- Add [everforest] theme support.
|
||||
- Add [oil-git-status] support to [oil] module.
|
||||
|
||||
[Haskex](https://github.com/haskex):
|
||||
|
||||
|
|
@ -479,13 +508,8 @@
|
|||
|
||||
- fix broken `neorg` grammars
|
||||
- remove obsolete warning in the `otter` module
|
||||
|
||||
[Cool-Game-Dev](https://github.com/Cool-Game-Dev):
|
||||
|
||||
[nvim-biscuits]: https://github.com/code-biscuits/nvim-biscuits
|
||||
|
||||
- Add [nvim-biscuits] to show block context. Available at
|
||||
`vim.utility.nvim-biscuits`.
|
||||
- add mainProgram attribute to vala language server wrapper
|
||||
- fix `crates-nvim`'s completions by using the in-program lsp
|
||||
|
||||
[JManch](https://github.com/JManch):
|
||||
|
||||
|
|
@ -493,6 +517,56 @@
|
|||
`autocomplete.nvim-cmp.enable` was disabled and
|
||||
`autocomplete.nvim-cmp.sources` had not been modified.
|
||||
|
||||
[Poseidon](https://github.com/poseidon-rises):
|
||||
|
||||
[nvim-biscuits]: https://github.com/code-biscuits/nvim-biscuits
|
||||
[just-lsp]: https://github.com/terror/just-lsp
|
||||
[roslyn-ls]: https://github.com/dotnet/vscode-csharp
|
||||
[jsonls]: https://github.com/microsoft/vscode/tree/1.101.2/extensions/json-language-features/server
|
||||
[jsonfmt]: https://github.com/caarlos0/jsonfmt
|
||||
[superhtml]: https://github.com/kristoff-it/superhtml
|
||||
[htmlHINT]: https://github.com/htmlhint/HTMLHint
|
||||
[qmk-nvim]: https://github.com/codethread/qmk.nvim
|
||||
[qmlls]: https://doc.qt.io/qt-6/qtqml-tooling-qmlls.html
|
||||
[qmlformat]: https://doc.qt.io/qt-6/qtqml-tooling-qmlformat.html
|
||||
|
||||
- Add [nvim-biscuits] support under `vim.utility.nvim-biscuits`.
|
||||
- Add just support under `vim.languages.just` using [just-lsp].
|
||||
- Add [roslyn-ls] to the `vim.languages.csharp` module.
|
||||
- Add JSON support under `vim.languages.json` using [jsonls] and [jsonfmt].
|
||||
- Add advanced HTML support under `vim.languages.html` using [superhtml] and
|
||||
[htmlHINT].
|
||||
- Add QMK support under `vim.utility.qmk-nvim` via [qmk-nvim].
|
||||
- Add QML support under `vim.languages.qml` using [qmlls] and [qmlformat].
|
||||
|
||||
[Morsicus](https://github.com/Morsicus):
|
||||
|
||||
- Add [EEx Treesitter Grammar](https://github.com/connorlay/tree-sitter-eex) for
|
||||
Elixir
|
||||
- Add
|
||||
[HEEx Treesitter Grammar](https://github.com/phoenixframework/tree-sitter-heex)
|
||||
for Elixir
|
||||
|
||||
[diced](https://github.com/diced):
|
||||
|
||||
- Fixed `typescript` treesitter grammar not being included by default.
|
||||
|
||||
[valterschutz](https://github.com/valterschutz):
|
||||
|
||||
[ruff]: https://github.com/astral-sh/ruff
|
||||
|
||||
- Add [ruff-fix] as a formatter option in `vim.languages.python.format.type`.
|
||||
|
||||
[gmvar](https://github.com/gmvar):
|
||||
|
||||
[harper-ls]: https://github.com/Automattic/harper
|
||||
|
||||
- Add [harper-ls] to the `vim.lsp` module.
|
||||
|
||||
[derethil](https://github.com/derethil):
|
||||
|
||||
- Fix `vim.lazy.plugins.<name>.enabled` Lua evaluation.
|
||||
|
||||
[Jules](https://github.com/jules-sommer):
|
||||
|
||||
[nvim-highlight-colors]: https://github.com/brenoprata10/nvim-highlight-colors
|
||||
|
|
@ -511,6 +585,32 @@
|
|||
- Add inline typst concealing support under `vim.languages.typst` using
|
||||
[typst-concealer].
|
||||
|
||||
[KrappRamiro](https://github.com/KrappRamiro):
|
||||
|
||||
[phaazon/hop.nvim]: https://github.com/hadronized/hop.nvim
|
||||
[smoka7/hop.nvim]: https://github.com/smoka7/hop.nvim
|
||||
|
||||
- Migrate [phaazon/hop.nvim] to [smoka7/hop.nvim]
|
||||
|
||||
[simon-wg](https://github.com/simon-wg):
|
||||
|
||||
- Update `python` language module to use correct lsp binary.
|
||||
- Fix `python` pyright and basedpyright language servers not using default on
|
||||
attach behavior.
|
||||
|
||||
[critical](https://github.com/critical):
|
||||
|
||||
[mellow.nvim]: https://github.com/mellow-theme/mellow.nvim
|
||||
|
||||
- Add [mellow.nvim] plugin for vim and lualine theme support
|
||||
|
||||
[valyntyler](https://github.com/valyntyler):
|
||||
|
||||
[emmet-ls]: https://github.com/aca/emmet-ls
|
||||
|
||||
- Enable `languages.ts.format` for `.js` files
|
||||
- Add [emmet-ls] to `html.lsp.servers`
|
||||
|
||||
[axelbdt](https://github.com/axelbdt):
|
||||
|
||||
[neocodeium]: https://github.com/monkoose/neocodeium
|
||||
154
docs/manual/release-notes/rl-0.9.md
Normal file
154
docs/manual/release-notes/rl-0.9.md
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
# Release 0.9 {#sec-release-0-9}
|
||||
|
||||
## Breaking changes
|
||||
|
||||
- Nixpkgs has merged a fully incompatible rewrite of
|
||||
`vimPlugins.nvim-treesitter`. Namely, it changes from the frozen `master`
|
||||
branch to the new main branch. This change removes incremental selections, so
|
||||
it is no longer available.
|
||||
- [obsidian.nvim] now uses a maintained fork which has removed the `dir`
|
||||
setting. Use `workspaces` instead:
|
||||
|
||||
```nix
|
||||
{
|
||||
workspaces = [
|
||||
{
|
||||
name = "any-string";
|
||||
path = "~/old/dir/path/value";
|
||||
}
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
Some other settings and commands are now deprecated but are still supported.
|
||||
|
||||
- The `setupOpts.mappings` options were also removed. Use the built-in Neovim
|
||||
settings (nvf's {option}`vim.keymaps`)
|
||||
|
||||
## Changelog {#sec-release-0-9-changelog}
|
||||
|
||||
[taylrfnt](https://github.com/taylrfnt)
|
||||
|
||||
- Introduce a `darwinModule` option for Darwin users. The ergonomics of
|
||||
importing a `nixosModule` into a Darwin flake were less than ideal, and when
|
||||
users fork and update npins, they are prone to encountering errors like the
|
||||
following:
|
||||
|
||||
```shell
|
||||
(class: "nixos") cannot be imported into a module
|
||||
evaluation that expects class "darwin".
|
||||
```
|
||||
|
||||
[suimong](https://github.com/suimong):
|
||||
|
||||
- Fix `vim.tabline.nvimBufferline` where `setupOpts.options.hover` requires
|
||||
`vim.opt.mousemoveevent` to be set.
|
||||
|
||||
[thamenato](https://github.com/thamenato):
|
||||
|
||||
- Attempt to adapt nvim-treesitter to (breaking) Nixpkgs changes. Some
|
||||
treesitter grammars were changed to prefer `grammarPlugins` over
|
||||
`builtGrammars`.
|
||||
|
||||
[jfeo](https://github.com/jfeo):
|
||||
|
||||
[ccc.nvim]: https://github.com/uga-rosa/ccc.nvim
|
||||
|
||||
- Added [ccc.nvim] option {option}`vim.utility.ccc.setupOpts` with the existing
|
||||
hard-coded options as default values.
|
||||
|
||||
[Ring-A-Ding-Ding-Baby](https://github.com/Ring-A-Ding-Ding-Baby):
|
||||
|
||||
- Aligned `codelldb` adapter setup with [rustaceanvim]’s built-in logic.
|
||||
- Added `languages.rust.dap.backend` option to choose between `codelldb` and
|
||||
`lldb-dap` adapters.
|
||||
|
||||
[Libadoxon](https://github.com/Libadoxon):
|
||||
|
||||
- `toggleterm` open map now also works when in terminal mode
|
||||
|
||||
[jtliang24](https://github.com/jtliang24):
|
||||
|
||||
- Updated nix language plugin to use pkgs.nixfmt instead of
|
||||
pkgs.nixfmt-rfc-style
|
||||
|
||||
[alfarel](https://github.com/alfarelcynthesis):
|
||||
|
||||
[obsidian.nvim]: https://github.com/obsidian-nvim/obsidian.nvim
|
||||
[blink.cmp]: https://cmp.saghen.dev/
|
||||
[snacks.nvim]: https://github.com/folke/snacks.nvim
|
||||
[mini.nvim]: https://nvim-mini.org/mini.nvim/
|
||||
[telescope.nvim]: https://github.com/nvim-telescope/telescope.nvim
|
||||
[fzf-lua]: https://github.com/ibhagwan/fzf-lua
|
||||
[render-markdown.nvim]: https://github.com/MeanderingProgrammer/render-markdown.nvim
|
||||
[markview.nvim]: https://github.com/OXY2DEV/markview.nvim
|
||||
[which-key.nvim]: https://github.com/folke/which-key.nvim
|
||||
|
||||
- Upgrade [obsidian.nvim] to use a maintained fork, instead of the unmaintained
|
||||
upstream.
|
||||
- Various upstream improvements:
|
||||
- Support [blink.cmp] and completion plugin autodetection.
|
||||
- Support various pickers for prompts, including [snacks.nvim]'s
|
||||
`snacks.picker`, [mini.nvim]'s `mini.pick`, [telescope.nvim], and
|
||||
[fzf-lua].
|
||||
- Merge commands like `ObsidianBacklinks` into `Obisidian backlinks`. The
|
||||
old format is still supported by default.
|
||||
- Some `setupOpts` options have changed:
|
||||
- `disable_frontmatter` -> `frontmatter.enabled` (and inverted), still
|
||||
supported.
|
||||
- `note_frontmatter_func` -> `frontmatter.func`, still supported.
|
||||
- `statusline` module is now deprecated in favour of `footer`, still
|
||||
supported.
|
||||
- `dir` is no longer supported, use `workspaces`:
|
||||
|
||||
```nix
|
||||
{
|
||||
workspaces = [
|
||||
{
|
||||
name = "any-string";
|
||||
path = "~/old/dir/path/value";
|
||||
}
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
- `use_advanced_uri` -> `open.use_advanced_uri`.
|
||||
- Mappings are now expected to be set using the built-in Neovim APIs,
|
||||
managed by `vim.keymaps` in nvf, instead of `mappings` options.
|
||||
- Some option defaults have changed.
|
||||
- And more.
|
||||
- Automatically configure an enabled picker in the order mentioned above, if
|
||||
any are enabled.
|
||||
- Add integration with `snacks.image` for rendering workspace/vault assets.
|
||||
- Detect if [render-markdown.nvim] or [markview.nvim] are enabled and disable
|
||||
the `ui` module if so. It should work without this, but `render-markdown`'s
|
||||
{command}`:healthcheck` doesn't know that.
|
||||
- Remove [which-key.nvim] `<leader>o` `+Notes` description which did not
|
||||
actually correspond to any keybinds.
|
||||
|
||||
[pyrox0](https://github.com/pyrox0):
|
||||
|
||||
- Added [rumdl](https://github.com/rvben/rumdl) support to `languages.markdown`
|
||||
|
||||
- Added [sqruff](https://github.com/quarylabs/sqruff) support to `languages.sql`
|
||||
|
||||
- Added [Pyrefly](https://pyrefly.org/) and [zuban](https://zubanls.com/)
|
||||
support to `languages.python`
|
||||
|
||||
- Added TOML support via {option}`languages.toml` and the
|
||||
[Tombi](https://tombi-toml.github.io/tombi/) language server, linter, and
|
||||
formatter.
|
||||
|
||||
- Added [hlargs.nvim](https://github.com/m-demare/hlargs.nvim) support as
|
||||
`visuals.hlargs-nvim`.
|
||||
|
||||
[Machshev](https://github.com/machshev):
|
||||
|
||||
- Added `ruff` and `ty` LSP support for Python under `programs.python`.
|
||||
|
||||
[Snoweuph](https://github.com/snoweuph)
|
||||
|
||||
- Added [Selenen](https://github.com/kampfkarren/selene) for more diagnostics in
|
||||
`languages.lua`.
|
||||
|
||||
<!-- vim: set textwidth=80: -->
|
||||
|
|
@ -6,7 +6,7 @@ documentation, configuring **nvf** with pure Lua and using custom plugin sources
|
|||
in **nvf** in this section. For general configuration tips, please see previous
|
||||
chapters.
|
||||
|
||||
```{=include=} chapters
|
||||
```{=include=}
|
||||
tips/debugging-nvf.md
|
||||
tips/offline-docs.md
|
||||
tips/pure-lua-config.md
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ startup.
|
|||
}
|
||||
```
|
||||
|
||||
[`vim.extraPlugins`]: https://notashelf.github.io/nvf/options.html#opt-vim.extraPlugins
|
||||
[`vim.extraPlugins`]: ./options.html#option-vim-extraPlugins
|
||||
|
||||
This will fetch aerial.nvim from nixpkgs, and add it to Neovim's runtime path to
|
||||
be loaded manually. Although for plugins that require manual setup, you are
|
||||
|
|
@ -43,7 +43,7 @@ encouraged to use [`vim.extraPlugins`].
|
|||
}
|
||||
```
|
||||
|
||||
[custom plugins section]: https://notashelf.github.io/nvf/index.xhtml#ch-custom-plugins
|
||||
[custom plugins section]: ./configuring.html#ch-custom-plugins
|
||||
|
||||
More details on the extraPlugins API is documented in the
|
||||
[custom plugins section].
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ manner.
|
|||
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 [](#opt-vim.luaConfigRC).
|
||||
directory, and call it with {option}`vim.luaConfigRC`.
|
||||
|
||||
```nix
|
||||
{pkgs, ...}: {
|
||||
|
|
@ -90,7 +90,7 @@ vim.keymap.set("n", " ", "<Nop>", { silent = true, remap = false })
|
|||
vim.g.mapleader = " "
|
||||
```
|
||||
|
||||
The following Nix configuration via [](#opt-vim.luaConfigRC) will allow loading
|
||||
The following Nix configuration via {option}`vim.luaConfigRC` will allow loading
|
||||
this
|
||||
|
||||
```nix
|
||||
|
|
@ -105,7 +105,7 @@ this
|
|||
}
|
||||
```
|
||||
|
||||
[DAG system]: https://notashelf.github.io/nvf/index.xhtml#ch-using-dags
|
||||
[DAG system]: ./configuring.html#ch-using-dags
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,72 +0,0 @@
|
|||
# Try it out {#ch-try-it-out}
|
||||
|
||||
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** (`packages.nix`) - Nix language server + simple utility plugins
|
||||
- **Maximal** (`packages.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.
|
||||
|
||||
```sh
|
||||
$ 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 that
|
||||
the built outputs will be removed from your Nix store once you garbage collect.
|
||||
|
||||
## Using Prebuilt Configs {#sec-using-prebuilt-configs}
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#nix
|
||||
$ nix run github:notashelf/nvf#maximal
|
||||
```
|
||||
|
||||
### Available Configurations {#sec-available-configs}
|
||||
|
||||
::: {.info}
|
||||
|
||||
The below configurations are provided for demonstration purposes, and are
|
||||
**not** designed to be installed as is. You may
|
||||
|
||||
#### Nix {#sec-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.
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#nix test.nix
|
||||
```
|
||||
|
||||
This command will start Neovim with some opinionated plugin configurations, and
|
||||
is designed specifically for Nix. the `nix` configuration lets you see how a
|
||||
fully configured Neovim setup _might_ look like without downloading too many
|
||||
packages or shell utilities.
|
||||
|
||||
#### Maximal {#sec-configs-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.
|
||||
|
||||
```bash
|
||||
$ nix run github:notashelf/nvf#maximal -- test.nix
|
||||
```
|
||||
|
||||
It uses the same configuration template with the [Nix](#sec-configs-nix)
|
||||
configuration, but supports many more languages, and enables more utility,
|
||||
companion or fun plugins.
|
||||
|
||||
::: {.warning}
|
||||
|
||||
Running the maximal config will download _a lot_ of packages as it is
|
||||
downloading language servers, formatters, and more. If CPU time and bandwidth
|
||||
are concerns, please use the default package instead.
|
||||
|
||||
:::
|
||||
28
docs/ndg.toml
Normal file
28
docs/ndg.toml
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# NDG Configuration File
|
||||
|
||||
# Input directory containing markdown files
|
||||
input_dir = "docs"
|
||||
|
||||
# Output directory for generated documentation
|
||||
output_dir = "build"
|
||||
|
||||
# Title for the documentation
|
||||
title = "NVF"
|
||||
|
||||
# Footer text for the documentation
|
||||
footer_text = "Generated with ndg"
|
||||
|
||||
generate_anchors = true
|
||||
|
||||
# Search configuration
|
||||
[search]
|
||||
enable = true
|
||||
highlight_code = true
|
||||
tab_style = "none"
|
||||
revision = "main"
|
||||
|
||||
# Maximum heading level to index
|
||||
max_heading_level = 3
|
||||
|
||||
# Depth of parent categories in options TOC
|
||||
options_toc_depth = 2
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
# Release Notes {#ch-release-notes}
|
||||
|
||||
This section lists the release notes for tagged version of **nvf** and the
|
||||
current main current main branch
|
||||
|
||||
```{=include=} chapters
|
||||
rl-0.1.md
|
||||
rl-0.2.md
|
||||
rl-0.3.md
|
||||
rl-0.4.md
|
||||
rl-0.5.md
|
||||
rl-0.6.md
|
||||
rl-0.7.md
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue