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

treewide: find and fix typos

Browse source
This commit is contained in:
raf 2024-11-26 10:36:39 +03:00
commit c2de643f19
Signed by: NotAShelf
GPG key ID: AF26552424E53993
21 changed files with 30 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -4,12 +4,12 @@ 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
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 fullfills our
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

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

@ -93,10 +93,10 @@ the commit followed by the description:
```
languages/ruby: init module
Adds a language module for Ruby, adds appropriate formatters and Treesitter grammers
Adds a language module for Ruby, adds appropriate formatters and Treesitter grammars
```
Long description can be ommitted if the change is too simple to warrant it. A
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.

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

@ -1,13 +1,13 @@
# Testing Changes {#sec-testing-changes}
Once you have made your changes, you will need to test them throughly. If it is
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 posssible.
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