NotAShelf/nvf
1
0
Fork 0
mirror of https://github.com/NotAShelf/nvf.git synced 2024-11-26 15:06:45 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

docs/hacking: add testing section

Browse source
This commit is contained in:
raf 2023-10-01 16:27:53 +03:00
parent e5df60172a
commit 1463d2444a
No known key found for this signature in database
GPG key ID: 02D1DD3FA08B6B29
1 changed files with 24 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
docs/manual/hacking.adoc
View file

@ -1,9 +1,17 @@
[[ch-hacking]]
== Hacking neovim-flake
<<<<<<< HEAD
<<<<<<< HEAD
neovim-flake is designed for developers as much as it is for the end user. I would like any potential contributor
to be able to propagate their desired changes into the repository without the extra effort. As such, below are guides
||||||| parent of 33dd7b0 (docs/hacking: add testing section)
neovim-flake is designed for developers as much as it is for the end user. I would like any potential contributor
to be able to propagate their desired changes into the repository without the extra effort. As such, below are guides
=======
neovim-flake is designed for developers as much as it is for the end user. I would like any potential contributor to
be able to propagate their desired changes into the repository without the extra effort. As such, below are guides
>>>>>>> 33dd7b0 (docs/hacking: add testing section)
(and guidelines) to streamline the contribution process and ensure that your valuable input seamlessly integrates
||||||| parent of c609a56 (among us)
neovim-flake is designed for developers as much as it is for the end user. I would like any potential contributor to
@ -35,8 +43,8 @@ You naturally would like to start by forking the repository. If you are new to g
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`.
Implement your changes and commit them to the newly created branch and when you are happy with the result and positive that it
fulfills <<sec-guidelines>>. Once you are confident everything is in order, push the branch to GitHub and
Implement your changes and commit them to the newly created branch and when you are happy with the result and positive
that it fulfills <<sec-guidelines>>. Once you are confident everything is in order, push the branch to GitHub and
{create-a-pull-request}[create a pull request], following the template that you will be prompted to fill.
[[sec-guidelines]]
@ -201,8 +209,22 @@ listToBeAvoided = [item1 item2 /* comment */ item3 item4];
singleItemList = [item1];
----
[[sec-testing]]
=== Testing Your 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.
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.
[[sec-keybinds]]
=== 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 https://github.com/NotAShelf/neovim-flake/tree/main/lib[extended standard library]. The following section contains
a general overview to how you may utilize said functions.