NotAShelf/nvf
2
1
Fork 0
mirror of https://github.com/NotAShelf/nvf.git synced 2025-09-07 19:01:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: rename all instances of neovim-flake to nvf

Browse source
This commit is contained in:
raf 2024-04-27 15:44:37 +03:00
commit 227f80ac9d
No known key found for this signature in database
GPG key ID: 02D1DD3FA08B6B29
36 changed files with 430 additions and 278 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/manual/hacking/additional-plugins.md
View file

@ -1,6 +1,6 @@
# Adding Plugins {#sec-additional-plugins}
To add a new neovim plugin, first add the source url in the inputs section of `flake.nix`
To add a new Neovim plugin, first add the source url in the inputs section of `flake.nix`
with the prefix `plugin-`
```nix
@ -17,7 +17,7 @@ with the prefix `plugin-`
}
```
The addition of the `plugin-` prefix will allow neovim-flake to autodiscover the
The addition of the `plugin-` prefix will allow **nvf** to autodiscover the
input from the flake inputs automatically, allowing you to refer to it in areas
that require a very specific plugin type as defined in `lib/types/plugins.nix`

20
docs/manual/hacking/getting-started.md
View file

@ -1,10 +1,16 @@
# Getting Started {#sec-contrib-getting-started}
You naturally would like to start by forking the repository. If you are new to git, have a look at GitHub's
[Fork a repo guide](https://help.github.com/articles/fork-a-repo/) for instructions on how you can do this. Once you have a fork of neovim-flake
you should create a branch starting at the most recent `main` branch.
Give your branch a reasonably descriptive name, suffixed by its type - i.e `feature/debugger` or `fix/pesky-bug`.
You, naturally, would like to start by forking the repository to get started. If
you are new to Git and GitHub, do have a look at GitHub's [Fork a repo guide](https://help.github.com/articles/fork-a-repo/)
for instructions on how you can do this. Once you have a fork of **nvf**, you
should create a separate branch based on the msot recent `main` branch. Give
your branch a reasonably descriptive name (e.g. `feature/debugger` or
`fix/pesky-bug`) and you are ready to work on your changes
Implement your changes and commit them to the newly created branch and when you are happy with the result and positive
that it fulfills [Guidelines](#sec-guidelines). Once you are confident everything is in order, push the branch to GitHub and
[create a pull request](https://help.github.com/articles/creating-a-pull-request), following the template that you will be prompted to fill.
Implement your changes and commit them to the newly created branch and when you
are happy with the result, and positive that it fullfills our [Contributing
Guidelines](#sec-guidelines), push the branch to GitHub and [create a pull
request](https://help.github.com/articles/creating-a-pull-request). The default
pull request template available on the **nvf** repository will guide you through
the rest of the process, and we'll gently nudge you in the correct direction if
there are any mistakes.

143
docs/manual/hacking/guidelines.md
View file

@ -1,55 +1,65 @@
# Guidelines {#sec-guidelines}
If your contribution tightly follows the guidelines, then there is a good chance it will be merged without too much
trouble. Some of the guidelines will be strictly enforced, others will remain as gentle nudges towards the correct
direction. As we have no automated system enforcing those guidelines, please try to double check your changes before
making your pull request in order to avoid "faulty" code slipping by.
If your contribution tightly follows the guidelines, then there is a good chance
it will be merged without too much trouble. Some of the guidelines will be
strictly enforced, others will remain as gentle nudges towards the correct
direction. As we have no automated system enforcing those guidelines, please
try to double check your changes before making your pull request in order to
avoid "faulty" code slipping by.
If you are uncertain how these rules affect the change you would like to make then feel free to start a
discussion in the [discussions tab](https://github.com/NotAShelf/neovim-flake/discussions) ideally (but not necessarily)
before you start developing.
If you are uncertain how these rules affect the change you would like to make
then feel free to start a discussion in the [discussions tab](https://github.com/NotAShelf/nvf/discussions)
ideally (but not necessarily) before you start developing.
## Adding Documentation {#sec-guidelines-documentation}
Most, if not all, changes warrant changes to the documentation. Module options should be documented with
[Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup), albeit with exceptions.
:::{.note}
As of v0.5, neovim-flake is itself documented using full markdown in both module options and the manual. With
v0.6, this manual has also been converted to markdown in full.
Most, if not all, changes warrant changes to the documentation. Module options
should be documented with [Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup),
albeit with exceptions.
::: {.note}
As of **v0.5**, **vf** is itself documented using full markdown in both module
options and the manual. With **v0.6**, this manual has also been converted to
markdown in full.
:::
The HTML version of this manual containing both the module option descriptions and the documentation of neovim-flake
(such as this page) can be generated and opened by typing the following in a shell within a clone of the
neovim-flake Git repository:
The HTML version of this manual containing both the module option descriptions
and the documentation of **nvf** (such as this page) can be generated and
opened by typing the following in a shell within a clone of the **nvf** Git
repository:
```console
$ nix build .#docs-html
$ xdg-open $PWD/result/share/doc/neovim-flake/index.html
$ xdg-open $PWD/result/share/doc/nvf/index.html
```
## Formatting Code {#sec-guidelines-formatting}
Make sure your code is formatted as described in [code-style section](#sec-guidelines-code-style). To maintain consistency throughout
the project you are encouraged to browse through existing code and adopt its style also in new code.
Make sure your code is formatted as described in [code-style
section](#sec-guidelines-code-style). To maintain consistency throughout the
project you are encouraged to browse through existing code and adopt its style
also in new code.
## Formatting Commits {#sec-guidelines-commit-message-style}
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a consistent commit message format as described
in [commit style guidelines](#sec-guidelines-commit-style).
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a
consistent commit message format as described in [commit style
guidelines](#sec-guidelines-commit-style).
## Commit Style {#sec-guidelines-commit-style}
The commits in your pull request should be reasonably self-contained. Which means each and every commit in
a pull request should make sense both on its own and in general context. That is, a second commit should not resolve
an issue that is introduced in an earlier commit. In particular, you will be asked to amend any commit that
introduces syntax errors or similar problems even if they are fixed in a later commit.
The commits in your pull request should be reasonably self-contained. Which
means each and every commit in a pull request should make sense both on its
own and in general context. That is, a second commit should not resolve an
issue that is introduced in an earlier commit. In particular, you will be
asked to amend any commit that introduces syntax errors or similar problems
even if they are fixed in a later commit.
The commit messages should follow the [seven rules](https://chris.beams.io/posts/git-commit/#seven-rule),
except for "Capitalize the subject line". We also ask you to include the affected code component or module in
the first line. A commit message ideally, but not necessarily, follow the given template from home-manager's own documentation
The commit messages should follow the [seven
rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
"Capitalize the subject line". We also ask you to include the affected code
component or module in the first line. A commit message ideally, but not
necessarily, follow the given template from home-manager's own documentation
```
{component}: {description}
@ -57,15 +67,18 @@ the first line. A commit message ideally, but not necessarily, follow the given
{long description}
```
where `{component}` refers to the code component (or module) your change affects, `{description}` is a very brief
description of your change, and `{long description}` is an optional clarifying description. As a rare exception, if
there is no clear component, or your change affects many components, then the `{component}` part is optional.
See [example commit message](#sec-guidelines-ex-commit-message) for a commit message that fulfills these requirements.
where `{component}` refers to the code component (or module) your change
affects, `{description}` is a very brief description of your change, and
`{long description}` is an optional clarifying description. As a rare
exception, if there is no clear component, or your change affects many
components, then the `{component}` part is optional. See [example commit
message](#sec-guidelines-ex-commit-message) for a commit message that
fulfills these requirements.
## Example Commit {#sec-guidelines-ex-commit-message}
The commit [69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
in home-manager contains the commit message
in home-manager contains the following commit message.
```
starship: allow running in Emacs if vterm is used
@ -74,38 +87,43 @@ The vterm buffer is backed by libvterm and can handle Starship prompts
without issues.
```
Similarly, if you are contributing to neovim-flake, you would include the scope of the commit followed by
the description
Similarly, if you are contributing to **nvf**, you would include the scope of
the commit followed by the description:
```
languages/ruby: init module
Adds a language module for Ruby, and adds appropriate formatters and TS grammers
Adds a language module for Ruby, adds appropriate formatters and Treesitter grammers
```
Long description can be ommitted if the change is too simple to warrant it. A minor fix in spelling or a formatting
change does not warrant long description, however, a module addition or removal does as you would like to provide the
relevant context, e.g. the reasoning behind it, for your commit.
Long description can be ommitted if the change is too simple to warrant it. A
minor fix in spelling or a formatting change does not warrant long description,
however, a module addition or removal does as you would like to provide the
relevant context, i.e. the reasoning behind it, for your commit.
Finally, when adding a new module, say `modules/foo.nix`, we use the fixed commit format `foo: add module`.
You can, of course, still include a long description if you wish.
Finally, when adding a new module, say `modules/foo.nix`, we use the fixed
commit format `foo: add module`. You can, of course, still include a long
description if you wish.
In case of nested modules, i.e `modules/languages/java.nix` you are recommended to contain the parent as well - for
example `languages/java: some major change`.
In case of nested modules, i.e `modules/languages/java.nix` you are recommended
to contain the parent as well - for example `languages/java: some major change`.
## Code Style {#sec-guidelines-code-style}
**Treewide**
Keep lines at a reasonable width, ideally 80 characters or less. This also applies to string literals and module
descriptions and documentation.
### Treewide
**Nix**
neovim-flake is formatted by the [alejandra](https://github.com/kamadorueda/alejandra) tool and the formatting is checked in the pull
request and push workflows. Run the `nix fmt` command inside the project repository before submitting your
pull request.
Keep lines at a reasonable width, ideally 80 characters or less. This also applies
to string literals and module descriptions and documentation.
While Alejandra is mostly opinionated on how code looks after formatting, certain changes are done at the
user's discretion based on how the original code was structured.
### Nix
**nvf** is formatted by the [alejandra](https://github.com/kamadorueda/alejandra)
tool and the formatting is checked in the pull request and push workflows. Run the
`nix fmt` command inside the project repository before submitting your pull request.
While Alejandra is mostly opinionated on how code looks after formatting,
certain changes are done at the user's discretion based on how the original
code was structured.
Please use one line code for attribute sets that contain only one subset.
For example:
@ -128,8 +146,8 @@ module = {
}
```
If you move a line down after the merge operator, Alejandra will automatically unfold the whole merged attrset
for you, which we **do not** want.
If you move a line down after the merge operator, Alejandra will automatically
unfold the whole merged attrset for you, which we **do not** want.
```nix
module = {
@ -139,13 +157,12 @@ module = {
}
```
For lists, it is mostly up to your own discretion how you want to format them, but please try to unfold lists if
they contain multiple items and especially if they are to include comments.
For lists, it is mostly up to your own discretion how you want to format them,
but please try to unfold lists if they contain multiple items and especially
if they are to include comments.
```nix
# this is ok
acceptableList = [
item1 # comment
item2
@ -157,10 +174,12 @@ acceptableList = [
listToBeAvoided = [item1 item2 /* comment */ item3 item4];
# this is ok
acceptableList = [item1];
acceptableList = [item1 item2];
# this is not ok
listToBeAvoided = [
# this is also ok if the list is expected to contain more elements
acceptableList= [
item1
item2
# more items if needed...
];
```

72
docs/manual/hacking/keybinds.md
View file

@ -1,8 +1,9 @@
# Keybinds {#sec-keybinds}
As of 0.4, there exists an API for writing your own keybinds and a couple of useful utility functions are available in
the [extended standard library](https://github.com/NotAShelf/neovim-flake/tree/main/lib). The following section contains
a general overview to how you may utilize said functions.
As of 0.4, there exists an API for writing your own keybinds and a couple of
useful utility functions are available in the [extended standard
library](https://github.com/NotAShelf/nvf/tree/main/lib). The following
section contains a general overview to how you may utilize said functions.
## Custom Key Mappings Support for a Plugin {#sec-custom-key-mappings}
@ -36,44 +37,58 @@ An example, simple keybinding, can look like this:
```
There are many settings available in the options. Please refer to the
[documentation](https://notashelf.github.io/neovim-flake/options.html#opt-vim.maps.command._name_.action)
[documentation](https://notashelf.github.io/nvf/options.html#opt-vim.maps.command._name_.action)
to see a list of them.
`neovim-flake` provides a list of helper commands, so that you don't have to write the mapping attribute sets every
time:
**nvf** provides a list of helper commands, so that you don't have to write the
mapping attribute sets every time:
- `mkBinding = key: action: desc:` - makes a basic binding, with `silent` set to true.
- `mkExprBinding = key: action: desc:` - makes an expression binding, with `lua`, `silent`, and `expr` set to true.
- `mkLuaBinding = key: action: desc:` - makes an expression binding, with `lua`, and `silent` set to true.
- `mkBinding = key: action: desc:` - makes a basic binding, with `silent` set
to true.
- `mkExprBinding = key: action: desc:` - makes an expression binding, with
`lua`, `silent`, and `expr` set to true.
- `mkLuaBinding = key: action: desc:` - makes an expression binding, with
`lua`, and `silent` set to true.
Note that the Lua in these bindings is actual Lua, not pasted into a `:lua` command.
Therefore, you either pass in a function like `require('someplugin').some_function`, without actually calling it,
or you define your own function, like `function() require('someplugin').some_function() end`.
Do note that the Lua in these bindings is actual Lua, and not pasted into a
`:lua` command. Therefore, you should either pass in a function like
`require('someplugin').some_function`, without actually calling it, or you
should define your own functions, for example
Additionally, to not have to repeat the descriptions, there's another utility function with its own set of functions:
```lua
function()
require('someplugin').some_function()
end
```
Utility function that takes two attrsets:
Additionally, to not have to repeat the descriptions, there's another utility
function with its own set of functions: Utility function that takes two
attribute sets:
- `{ someKey = "some_value" }`
- `{ someKey = { description = "Some Description"; }; }`
and merges them into `{ someKey = { value = "some_value"; description = "Some Description"; }; }`
```
```nix
addDescriptionsToMappings = actualMappings: mappingDefinitions:
```
This function can be used in combination with the same `mkBinding` functions as above, except they only take two
arguments - `binding` and `action`, and have different names:
This function can be used in combination with the same `mkBinding` functions as
above, except they only take two arguments - `binding` and `action`, and have
different names:
- `mkSetBinding = binding: action:` - makes a basic binding, with `silent` set to true.
- `mkSetExprBinding = binding: action:` - makes an expression binding, with `lua`, `silent`, and `expr` set to true.
- `mkSetLuaBinding = binding: action:` - makes an expression binding, with `lua`, and `silent` set to true.
- `mkSetBinding = binding: action:` - makes a basic binding, with `silent`
set to true.
- `mkSetExprBinding = binding: action:` - makes an expression binding, with
`lua`, `silent`, and `expr` set to true.
- `mkSetLuaBinding = binding: action:` - makes an expression binding, with
`lua`, and `silent` set to true.
You can read the source code of some modules to see them in action, but their usage should look something like this:
You can read the source code of some modules to see them in action, but their
usage should look something like this:
```nix
# plugindefinition.nix
{lib, ...}: with lib; {
options.vim.plugin = {
@ -96,15 +111,13 @@ You can read the source code of some modules to see them in action, but their us
};
}
```
```nix
# config.nix
{
pkgs,
config,
pkgs,
lib,
...
}:
@ -158,9 +171,8 @@ in {
```
:::{.note}
If you have come across a plugin that has an API that doesn't seem to easily allow custom keybindings,
don't be scared to implement a draft PR. We'll help you get it done.
::: {.note}
If you have come across a plugin that has an API that doesn't seem to easily
allow custom keybindings, don't be scared to implement a draft PR. We'll help
you get it done.
:::

20
docs/manual/hacking/testing.md
View file

@ -1,11 +1,15 @@
# Testing Changes {#sec-testing-changes}
Once you have made your changes, you will need to test them throughly. If it is a module, add your module option to
`configuration.nix` (located in the root of this project) inside `neovimConfiguration`. Enable it, and then run the
maximal configuration with `nix run .#maximal -Lv` to check for build errors. If neovim opens in the current directory
without any error messages (you can check the output of `:messages` inside neovim to see if there are any errors), then
your changes are good to go. Open your pull request, and it will be reviewed as soon as posssible.
Once you have made your changes, you will need to test them throughly. If it is
a module, add your module option to `configuration.nix` (located in the root of
this project) inside `neovimConfiguration`. Enable it, and then run the maximal
configuration with `nix run .#maximal -Lv` to check for build errors. If neovim
opens in the current directory without any error messages (you can check the
output of `:messages` inside neovim to see if there are any errors), then your
changes are good to go. Open your pull request, and it will be reviewed as soon
as posssible.
If it is not a new module, but a change to an existing one, then make sure the module you have changed is enabled in the
maximal configuration by editing `configuration.nix`, and then run it with `nix run .#maximal -Lv`. Same procedure as
adding a new module will apply here.
If it is not a new module, but a change to an existing one, then make sure the
module you have changed is enabled in the maximal configuration by editing
`configuration.nix`, and then run it with `nix run .#maximal -Lv`. Same procedure
as adding a new module will apply here.