fix(docs): correct various typos

docs/src/3-syntax-highlighting.md

@@ -58,7 +58,7 @@ multiple grammars matched the file using the above two criteria. If the regex ma
 another grammar with no `content-regex`. If the regex does not match, a grammar with no `content-regex` will be preferred
 over this one.
 
-- `injection-regex` — A regex pattern that will be tested against a *language name* ito determine whether this language
+- `injection-regex` — A regex pattern that will be tested against a *language name* to determine whether this language
 should be used for a potential *language injection* site. Language injection is described in more detail in [a later section](#language-injection).
 
 ### Query Paths
@@ -77,7 +77,7 @@ Tree-sitter's syntax highlighting system is based on *tree queries*, which are a
 Tree-sitter's syntax trees. See [this section][pattern matching] of the documentation for more information about tree queries.
 
 Syntax highlighting is controlled by *three* different types of query files that are usually included in the `queries` folder.
-The default names for the query files use the `.scm` file. We chose this extension because it commonly used for files written
+The default names for the query files use the `.scm` file. We chose this extension because it is commonly used for files written
 in [Scheme][scheme], a popular dialect of Lisp, and these query files use a Lisp-like syntax.
 
 ### Highlights
@@ -123,7 +123,7 @@ Suppose we wanted to render this code with the following colors:
 - keywords `func` and `return` in purple
 - function `increment` in blue
 - type `int` in green
-- number `5` brown
+- number `5` in brown
 
 We can assign each of these categories a *highlight name* using a query like this:
 
@@ -169,7 +169,7 @@ Ideally, if a given entity appears in *multiple* places, it should be colored th
 highlighting system can help you to achieve this by keeping track of local scopes and variables.
 
 The *local variables* query is different from the highlights query in that, while the highlights query uses *arbitrary*
-capture names, which can then be mapped to colors, the locals variable query uses a fixed set of capture names, each of
+capture names, which can then be mapped to colors, the local variables query uses a fixed set of capture names, each of
 which has a special meaning.
 
 The capture names are as follows:
@@ -317,11 +317,11 @@ Some source files contain code written in multiple different languages. Examples
 
 - HTML files, which can contain JavaScript inside `<script>` tags and CSS inside `<style>` tags
 - [ERB][erb] files, which contain Ruby inside `<% %>` tags, and HTML outside those tags
-- PHP files, which can contain  HTML between the `<php` tags
+- PHP files, which can contain HTML between the `<php` tags
 - JavaScript files, which contain regular expression syntax within regex literals
 - Ruby, which can contain snippets of code inside heredoc literals, where the heredoc delimiter often indicates the language
 
-All of these examples can be modeled in terms a *parent* syntax tree and one or more *injected* syntax trees, which reside
+All of these examples can be modeled in terms of a *parent* syntax tree and one or more *injected* syntax trees, which reside
 *inside* of certain nodes in the parent tree. The language injection query allows you to specify these "injections" using
 the following captures:
 

docs/src/6-contributing.md

@@ -181,7 +181,7 @@ On average, minor releases should happen 1-3 times a year.
 
 Patch releases (`0.x.y`) are made from the **`release-0.x` branch** following these steps:
 1. Bump all version numbers (except for the language crate) to `0.x.y` as described above.
-2. Create a "release `v0.x.y` PR on `release-0.x` and apply the `ci:check release` label.
+2. Create a "release `v0.x.y`" PR on `release-0.x` and apply the `ci:check release` label.
 3. If the check release workflow indicates, bump the patch version of the language crate.
 4. Once the PR is merged, tag the commit accordingly: `tag v0.x.y` and push via `git push --tags` (maintainers only). This will trigger the release and publish workflows.
 5. Edit the Github release to include release notes (auto-generated, if nothing else).

docs/src/creating-parsers/2-the-grammar-dsl.md

@@ -22,7 +22,7 @@ DSL through the `RustRegex` class. Simply pass your regex pattern as a string:
 
   ```admonish note 
   Only a subset of the Regex engine is actually supported. This is due to certain features like lookahead and lookaround
-  assertions not feasible to use in an LR(1) grammar, as well as certain flags being unnecessary for tree-sitter. However,
+  assertions not being feasible to use in an LR(1) grammar, as well as certain flags being unnecessary for tree-sitter. However,
   plenty of features are supported by default:
 
   - Character classes

docs/src/creating-parsers/3-writing-the-grammar.md

@@ -25,7 +25,7 @@ It's usually a good idea to find a formal specification for the language you're
 most likely contain a context-free grammar. As you read through the rules of this CFG, you will probably discover a complex
 and cyclic graph of relationships. It might be unclear how you should navigate this graph as you define your grammar.
 
-Although languages have very different constructs, their constructs can often be categorized in to similar groups like
+Although languages have very different constructs, their constructs can often be categorized into similar groups like
 _Declarations_, _Definitions_, _Statements_, _Expressions_, _Types_ and _Patterns_. In writing your grammar, a good first
 step is to create just enough structure to include all of these basic _groups_ of symbols. For a language like Go,
 you might start with something like this:
@@ -372,7 +372,7 @@ structured like that, but this conflict is actually present in the
 
 ## Hiding Rules
 
-You may have noticed in the above examples that some grammar rule name like `_expression` and `_type` began with an underscore.
+You may have noticed in the above examples that some grammar rule names like `_expression` and `_type` began with an underscore.
 Starting a rule's name with an underscore causes the rule to be _hidden_ in the syntax tree. This is useful for rules like
 `_expression` in the grammars above, which always just wrap a single child node. If these nodes were not hidden, they would
 add substantial depth and noise to the syntax tree without making it any easier to understand.
@@ -515,7 +515,6 @@ module.exports = grammar({
     // ...
   },
 });
-_
 ```
 
 Although supertype rules are hidden from the syntax tree, they can still be used in queries. See the chapter on

docs/src/creating-parsers/4-external-scanners.md

@@ -100,7 +100,7 @@ void tree_sitter_my_language_external_scanner_deserialize(
 }
 ```
 
-This function should _restore_ the state of your scanner based the bytes that were previously written by the `serialize`
+This function should _restore_ the state of your scanner based on the bytes that were previously written by the `serialize`
 function. It is called with a pointer to your scanner, a pointer to the buffer of bytes, and the number of bytes that should
 be read. It is good practice to explicitly erase your scanner state variables at the start of this function, before restoring
 their values from the byte buffer.
@@ -118,7 +118,7 @@ to check if the next character (or set of characters) invalidates the token.
 
 - Return `true` from the scanning function, indicating that a token was successfully lexed.
 
-Tree-sitter will then push resulting node to the parse stack, and the input position will remain where it reached at the
+Tree-sitter will then push the resulting node to the parse stack, and the input position will remain where it reached at the
 point `lexer->mark_end` was called.
 
 ```c
@@ -219,7 +219,7 @@ void* tree_sitter_my_language_external_scanner_create() {
 If you need to use array-like types in your scanner, such as tracking a stack of indentations or tags, you should use the
 array macros from `tree_sitter/array.h`.
 
-There are quite a few of them provided for you, but here's how you could get started tracking some . Check out the header
+There are quite a few of them provided for you, but here's how you could get started tracking some state. Check out the header
 itself for more detailed documentation.
 
 ```admonish attention

docs/src/using-parsers/6-static-node-types.md

@@ -13,7 +13,7 @@ following entries:
 
 Every object in this array has these two entries:
 
-- `"type"` — A string that indicates, which grammar rule the node represents. This corresponds to the `ts_node_type` function
+- `"type"` — A string that indicates which grammar rule the node represents. This corresponds to the `ts_node_type` function
 described [here][syntax nodes].
 - `"named"` — A boolean that indicates whether this kind of node corresponds to a rule name in the grammar or just a string
 literal. See [here][named-vs-anonymous-nodes] for more info.

docs/src/using-parsers/queries/1-syntax.md

@@ -9,7 +9,7 @@ would match any `binary_expression` node whose children are both `number_literal
 (binary_expression (number_literal) (number_literal))
 ```
 
-Children can also be omitted. For example, this would match any `binary_expression` where at least _one_ of child is a
+Children can also be omitted. For example, this would match any `binary_expression` where at least _one_ of its children is a
 `string_literal` node:
 
 ```query
@@ -88,7 +88,7 @@ using `(MISSING)`:
 (MISSING) @missing-node
 ```
 
-This is useful when attempting to detect all syntax errors in a given parse tree, since these missing node are not captured
+This is useful when attempting to detect all syntax errors in a given parse tree, since these missing nodes are not captured
 by `(ERROR)` queries. Specific missing node types can also be queried:
 
 ```scheme

docs/src/using-parsers/queries/3-predicates-and-directives.md

@@ -13,7 +13,7 @@ This family of predicates allows you to match against a single capture or string
 value.
 
 The first argument to this predicate must be a capture, but the second can be either a capture to
-compare the two captures' text, or a string to compare first capture's text
+compare the two captures' text, or a string to compare the first capture's text
 against.
 
 The base predicate is `#eq?`, but its complement, `#not-eq?`, can be used to _not_
@@ -164,7 +164,7 @@ view the [code navigation](../../4-code-navigation.md#examples) documentation.
 
 ## Recap
 
-To recap about the predicates and directives Tree-Sitter's bindings support:
+To recap about the predicates and directives Tree-sitter's bindings support:
 
 - `#eq?` checks for a direct match against a capture or string