From 1463d2444a3ed5c6048c89575750645e7382ecce Mon Sep 17 00:00:00 2001 From: NotAShelf Date: Sun, 1 Oct 2023 16:27:53 +0300 Subject: [PATCH] docs/hacking: add testing section --- docs/manual/hacking.adoc | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/docs/manual/hacking.adoc b/docs/manual/hacking.adoc index d9b5331..66a5270 100644 --- a/docs/manual/hacking.adoc +++ b/docs/manual/hacking.adoc @@ -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 <>. 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 <>. 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.