Fixed a few typos in docs (#542)

* Fixed a few typos in docs

* Updated tests

README.md

@@ -154,7 +154,7 @@ The `plugin:regexp/all` config enables all rules. It's meant for testing, not fo
 | [no-useless-flag](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-flag.html)                                             | disallow unnecessary regex flags                                                           |    | ✅  | 🔧 |    |
 | [no-useless-lazy](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-lazy.html)                                             | disallow unnecessarily non-greedy quantifiers                                              | ✅  |    | 🔧 |    |
 | [no-useless-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-quantifier.html)                                 | disallow quantifiers that can be removed                                                   | ✅  |    | 🔧 | 💡 |
-| [no-useless-range](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-range.html)                                           | disallow unnecessary range of characters by using a hyphen                                 | ✅  |    | 🔧 |    |
+| [no-useless-range](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-range.html)                                           | disallow unnecessary character ranges                                                      | ✅  |    | 🔧 |    |
 | [no-useless-two-nums-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-two-nums-quantifier.html)               | disallow unnecessary `{n,m}` quantifier                                                    | ✅  |    | 🔧 |    |
 | [no-zero-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-zero-quantifier.html)                                       | disallow quantifiers with a maximum of zero                                                | ✅  |    |    | 💡 |
 | [optimal-lookaround-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/optimal-lookaround-quantifier.html)                 | disallow the alternatives of lookarounds that end with a non-constant quantifier           |    | ✅  |    |    |

docs/rules/confusing-quantifier.md

@@ -18,7 +18,7 @@ since: "v0.8.0"
 Confusing quantifiers are ones which imply one thing but don't deliver on that.
 
 An example of this is `(?:a?b*|c+){4}`. The group is quantified with `{4}` which
-implies that at least 4 characters will be matched but this is not the case. The
+implies that at least 4 characters will be matched, but this is not the case. The
 whole pattern will match the empty string. It does that because in the `a?b*`
 alternative, it's possible to choose 0 many `a` and `b`. So rather than `{4}`,
 `{0,4}` should be used to reflect the fact that the empty string can be matched.

docs/rules/hexadecimal-escape.md

@@ -17,7 +17,7 @@ since: "v0.9.0"
 
 Characters that can use hexadecimal escape can use both hexadecimal escape and unicode escape.
 
-This rule aims is enforces the consistent use of hexadecimal escapes.
+This rule aims to enforce the consistent use of hexadecimal escapes.
 
 <eslint-code-block fix>
 

docs/rules/index.md

@@ -61,7 +61,7 @@ sidebarDepth: 0
 | [no-useless-flag](no-useless-flag.md)                                             | disallow unnecessary regex flags                                                           |    | ✅  | 🔧 |    |
 | [no-useless-lazy](no-useless-lazy.md)                                             | disallow unnecessarily non-greedy quantifiers                                              | ✅  |    | 🔧 |    |
 | [no-useless-quantifier](no-useless-quantifier.md)                                 | disallow quantifiers that can be removed                                                   | ✅  |    | 🔧 | 💡 |
-| [no-useless-range](no-useless-range.md)                                           | disallow unnecessary range of characters by using a hyphen                                 | ✅  |    | 🔧 |    |
+| [no-useless-range](no-useless-range.md)                                           | disallow unnecessary character ranges                                                      | ✅  |    | 🔧 |    |
 | [no-useless-two-nums-quantifier](no-useless-two-nums-quantifier.md)               | disallow unnecessary `{n,m}` quantifier                                                    | ✅  |    | 🔧 |    |
 | [no-zero-quantifier](no-zero-quantifier.md)                                       | disallow quantifiers with a maximum of zero                                                | ✅  |    |    | 💡 |
 | [optimal-lookaround-quantifier](optimal-lookaround-quantifier.md)                 | disallow the alternatives of lookarounds that end with a non-constant quantifier           |    | ✅  |    |    |

docs/rules/no-empty-lookarounds-assertion.md

@@ -23,7 +23,7 @@ An empty lookaround is a lookaround for which at least one path in the lookaroun
 
 **Examples:**
 
-- `(?=)`: One of simplest empty lookarounds.
+- `(?=)`: One of the simplest empty lookarounds.
 - `(?=a*)`: It is possible for `a*` to not consume characters, therefore the lookahead is _empty_.
 - `(?=a|b*)`: Only one path has to not consume characters. Since it is possible for `b*` to not consume characters, the lookahead is _empty_.
 - `(?=a|$)`: This is **not** an empty lookaround. `$` does not _consume_ characters but it does _assert_ characters. Similarly, all other standard assertions (`\b`, `\B`, `^`) are also not empty.

docs/rules/no-misleading-capturing-group.md

@@ -58,7 +58,7 @@ var foo = /^(a*).+/
 
   This rule will report quantifiers at the end of capturing groups that might backtrack for certain strings.
 
-  E.g. when `/^(a*).+$/m` is used to match the string `"aa"`, then `a*` will capture both `a`s at first, but is then force to give up the last `a` to `.+` to make the whole regex accept. So `(a*)` only capture the first `a`. This is misleading because one would expect that `(a*)` should capture all `a`s at the start of the string, but this is not the case.
+  E.g. when `/^(a*).+$/m` is used to match the string `"aa"`, then `a*` will capture both `a`s at first, but is then forced to give up the last `a` to `.+` to make the whole regex accept. So `(a*)` only capture the first `a`. This is misleading because one would expect that `(a*)` should capture all `a`s at the start of the string, but this is not the case.
 
   Because this behavior might be intentional, some users might want to turn off this type of reporting.
 

docs/rules/no-optional-assertion.md

@@ -17,7 +17,7 @@ since: "v0.9.0"
 
 Assertions that are quantified (directly or indirectly) can be considered optional if the quantifier has a minimum of zero.
 
-A simple example is the following pattern: `/a(?:$)*b/`. The `$` assertion will reject but if that happens, it will simply be ignored because of the `*` quantifier. The assertion is optional, serving no function whatsoever.
+A simple example is the following pattern: `/a(?:$)*b/`. The `$` assertion will reject, but if that happens it will simply be ignored because of the `*` quantifier. The assertion is optional, serving no function whatsoever.
 
 More generally, an assertion is optional, if there exists a parent quantifier with a minimum of zero such that all possible paths of the quantified element that contain the assertion do not consume characters.
 

docs/rules/no-super-linear-backtracking.md

@@ -67,7 +67,7 @@ Every input string that exploits super-linear worst-case runtime can be separate
 
 For some regexes it is not possible to find a rejecting suffix even though the regex contains exploitable ambiguity (e.g. `/(?:a+)+/`). These regexes are safe as long as they are used as is. However, regexes can also be used as building blocks to create more complex regexes. In this case, the ambiguity might cause super-linear backtracking in the composite regex.
 
-This options control whether ambiguity that might cause super-linear backtracking will be reported.
+These options control whether ambiguity that might cause super-linear backtracking will be reported.
 
 - `report: "certain"`  (_default_)
 

docs/rules/no-super-linear-move.md

@@ -39,7 +39,7 @@ var foo = /<.*?>/;
 
 Regexes are often used to find text of within a string (e.g. `/abc/.exec("123 abc def")`). The position of the matching text is unknown and has to be determined by the regex engine. In practice, the regex engine will move the regex across the input string character by character. While there are many optimizations to skip parts of the input string, there will still be _O(n)_ possible positions. If there is no text matching the regex in the input string, then all _O(n)_ positions will be checked.
 
-This is not problem in it self, _O(n)_ is expected for linear string searching algorithms.
+This is not a problem in itself, _O(n)_ is expected for linear string searching algorithms.
 
 Problems arise when the regex itself takes more than _O(1)_ steps (on average) to reject any position within the input.
 
@@ -65,7 +65,7 @@ This rule says that the first `\s*` causes quadratic runtime for "any attack str
 
 The problem with `\s*` is that `\s` also allows line break characters (the characters in the attack string). `^` already ensures the "start of a line" requirement, so there is no reason to allow line breaks after the `^`.
 
-The fix is to remove all line break characters from `\s`. This is difficult, so let's cheat a little and say that only spaces and tabs (`[\t ]`) are allows to surround the key.
+The fix is to remove all line break characters from `\s`. This is difficult, so let's cheat a little and say that only spaces and tabs (`[\t ]`) are allowed to surround the key.
 
 <eslint-code-block>
 
@@ -83,7 +83,7 @@ var fix = /^[\t ]*(\w+)[\t ]*[:=]/m
 
 #### Limit the quantifier
 
-All quantifiers reported by this rule are unbound (= maximum is infinite). This is because attackers need strings with a lengths >1000 character to exploit the quadratic runtime.
+All quantifiers reported by this rule are unbound (= maximum is infinite). This is because attackers need strings with lengths >1000 character to exploit the quadratic runtime.
 
 If the quantifier simply stops searching after some maximum number of steps, the quantifier isn't exploitable.
 

docs/rules/no-unused-capturing-group.md

@@ -69,7 +69,7 @@ This is by design. Capturing groups (as the name suggests) captured their matche
 
 A capturing group is intended to store its matched text so it can later be used, e.g. in text replacements.
 
-That makes a capturing group quite similar to a variable in that its value (the captured text) is stored (by the regex engine) and can be accessed afterward (by the developer). However, if the captured text is not used, then the capturing group will essentially be an unused variable. This makes the regex harder to understand because other developers will have to constantly ask themselves: "Is this a capturing group because the captured text will be used later on in the code, or because `()` is faster to type?"
+That makes a capturing group quite similar to a variable, in that its value (the captured text) is stored (by the regex engine) and can be accessed afterward (by the developer). However, if the captured text is not used, then the capturing group will essentially be an unused variable. This makes the regex harder to understand because other developers will have to constantly ask themselves: "Is this a capturing group because the captured text will be used later on in the code, or because `()` is faster to type?"
 
 Using capturing groups only if the captured text is used makes their usage unambiguous and easier for others to understand.
 

docs/rules/no-useless-backreference.md

@@ -25,7 +25,7 @@ Backreferences can be useless for multiple reasons.
 
 #### Empty capturing groups
 
-The is the easiest reason. The references capturing group does not consume any characters (e.g. `/(\b)a\1/`). Since the capturing group can only capture the empty string, the backreference is guaranteed to accept any input.
+The simplest reason. The references capturing group does not consume any characters (e.g. `/(\b)a\1/`). Since the capturing group can only capture the empty string, the backreference is guaranteed to accept any input.
 
 #### Nested backreferences
 
@@ -39,7 +39,7 @@ If a backreference and its referenced capturing group are in different alternati
 
 #### Forward references and backward references
 
-Backreferences are supposed to be matched **after** their referenced capturing group. Since regular expressions are matched from left to right, backreferences usually appear to the right of to their referenced capturing groups (e.g. `/(a)\1/`). However, backreferences can also be placed before (to the left of) their referenced capturing group (e.g. `/\1(a)/`). These backreferences are to trivially accept because the captured text of their referenced groups is undefined. We call these backreferences _forward references_.
+Backreferences are supposed to be matched **after** their referenced capturing group. Since regular expressions are matched from left to right, backreferences usually appear to the right of their referenced capturing groups (e.g. `/(a)\1/`). However, backreferences can also be placed before (to the left of) their referenced capturing group (e.g. `/\1(a)/`). These backreferences are to trivially accept because the captured text of their referenced groups is undefined. We call these backreferences _forward references_.
 
 Inside **lookbehind assertions**, regular expressions are matched from right to left and not from left to right. This means that only backreferences now have to appear to the left of their respective capturing group to be matched after them (e.g. `/(?<=\1(a))/`). Backreferences placed to before (to the right of) their referenced capturing group inside lookbehinds are guaranteed to trivially accept. We call these backreferences _backward references_.
 
@@ -50,7 +50,7 @@ If the referenced capturing group of a backreference is inside a negated lookaro
 To understand why this is the case, let's look at the example `/(?!(a))\w\1/y`.
 
 1. Let's assume the input string is `ab`. <br>
-   Since `(a)` accepts the character `a`, `(?!(a))` will reject. So the input is reject before the backreference `\1` can be reached.
+   Since `(a)` accepts the character `a`, `(?!(a))` will reject. So the input is rejected before the backreference `\1` can be reached.
 
    The result of `/(?!(a))\w\1/y.exec("ab")` is `null`.
 2. Let's assume the input string is `bc`. <br>

docs/rules/no-useless-lazy.md

@@ -29,7 +29,7 @@ There are two reasons why a lazy quantifier doesn't have to lazy:
 
    In the example above, the character `a` and the character `b` do not overlap. Therefore the quantifier `a+` is possessive.
 
-   Since an effectively possessive quantifier cannot give up characters to the expression after it, it doesn't matter whether the quantifier greedy or lazy. However, greedy quantifiers should be preferred because they require less characters to write and are easier to visually parse.
+   Since an effectively possessive quantifier cannot give up characters to the expression after it, it doesn't matter whether the quantifier greedy or lazy. However, greedy quantifiers should be preferred because they require fewer characters to write and are easier to visually parse.
 
 <eslint-code-block fix>
 

docs/rules/no-useless-quantifier.md

@@ -19,7 +19,7 @@ since: "v0.10.0"
 
 This rule reports quantifiers that can trivially be removed without affecting the pattern.
 
-This rule only fixes constant one quantifiers (e.g. `a{1}`). All other reported useless quantifiers hint at programmer oversight or fundamental problems with the pattern.
+This rule only fixes constant-one quantifiers (e.g. `a{1}`). All other reported useless quantifiers hint at programmer oversight or fundamental problems with the pattern.
 
 Examples:
 

docs/rules/no-useless-range.md

@@ -2,7 +2,7 @@
 pageClass: "rule-details"
 sidebarDepth: 0
 title: "regexp/no-useless-range"
-description: "disallow unnecessary range of characters by using a hyphen"
+description: "disallow unnecessary character ranges"
 since: "v0.3.0"
 ---
 # regexp/no-useless-range
@@ -17,7 +17,7 @@ since: "v0.3.0"
 
 ## :book: Rule Details
 
-This rule reports unnecessary range of characters by using a hyphen. e.g. `[a-a]`
+This rule reports unnecessary character ranges. E.g. `[a-a]`
 
 <eslint-code-block fix>
 

docs/rules/optimal-lookaround-quantifier.md

@@ -17,21 +17,20 @@ since: "v0.8.0"
 
 Non-constant quantifiers are quantifiers that describe a range (e.g. `?`, `*`,
 `+`, `{0,1}`, `{5,9}`, `{3,}`). They have to match some number of times (the
-minimum) after which further matches are optional until a certain maximum (may
-be infinite) is reached.
+minimum) after which further matches are optional until a certain maximum (potentially infinite) is reached.
 
 It's obvious that `/ba{2}/` and `/ba{2,6}/` will match differently because of
 the different quantifiers of `a` but that not the case if for lookarounds. Both
 `/b(?=a{2})/` and `/b(?=a{2,6})/` will match strings the same way. I.e. for the
 input string `"baaa"`, both will create the same match arrays. The two regular
-expression are actually equivalent, meaning that `(?=a{2})` is equivalent to
+expressions are actually equivalent, meaning that `(?=a{2})` is equivalent to
 `(?=a{2,6})`.
 
 More generally, if a non-constant quantifier is an **end** of the expression
 tree of a **lookahead**, that quantifier can be replaced with a constant
 quantifier that matched the element minimum-if-the-non-constant-quantifier many
 times. For **lookbehinds**, the non-constant quantifier has to be at the
-**start** of the expression tree as lookbehinds are matched from right to left.
+**start** of the expression tree, as lookbehinds are matched from right to left.
 
 <eslint-code-block>
 

docs/rules/optimal-quantifier-concatenation.md

@@ -59,7 +59,7 @@ var foo = /\w+(?:(a)|b)*/;
 
 ### `capturingGroups`
 
-The type of concatenation this rule reports might be intentional around capturing groups. This option allows you turn of false unfixable reports around capturing groups.
+The type of concatenation this rule reports might be intentional around capturing groups. This option allows you to turn off false unfixable reports around capturing groups.
 
 - `capturingGroups: "report"` (_default_)
 
@@ -69,7 +69,7 @@ The type of concatenation this rule reports might be intentional around capturin
 
   Concatenations around quantifiers will not be reported.
 
-  If this option is used, it is recommend to have the [regexp/no-super-linear-backtracking] rule enabled to protect against ReDoS.
+  If this option is used, it is recommended to have the [regexp/no-super-linear-backtracking] rule enabled to protect against ReDoS.
 
 ## :books: Further reading
 

docs/rules/prefer-escape-replacement-dollar-char.md

@@ -13,7 +13,7 @@ since: "v0.6.0"
 
 ## :book: Rule Details
 
-This rule aims to enforce escape when using the `$` character in replacement pattern of string replacement.
+This rule aims to enforce correct dollar sign escapes (`$$`) when using `$` in replacement pattern of string replacements.
 
 <eslint-code-block>
 

docs/rules/require-unicode-regexp.md

@@ -17,7 +17,7 @@ since: "v1.2.0"
 
 This rule reports regular expressions without the `u` flag.
 
-It will automatically add the `u` flag to regular expression where it is statically guaranteed to be safe to do so. In all other cases, the developer has to check that adding the `u` flag doesn't cause the regex to behave incorrectly.
+It will automatically add the `u` flag to regular expressions where it is statically guaranteed to be safe to do so. In all other cases, the developer has to check that adding the `u` flag doesn't cause the regex to behave incorrectly.
 
 This rule is inspired by the [require-unicode-regexp] rule. The position of the report is improved over the core rule and arguments of `new RegExp()` are also checked.
 

docs/rules/sort-alternatives.md

@@ -17,7 +17,7 @@ since: "v0.12.0"
 
 This rule will sort alternatives to improve readability and maintainability.
 
-The primary target of this rule are lists of words and/or numbers. These lists are somewhat common and sorting them makes it easy for readers to check whether a particular word or number is included.
+The primary target of this rule are lists of words and/or numbers. These lists are somewhat common, and sorting them makes it easy for readers to check whether a particular word or number is included.
 
 This rule will only sort alternatives if reordering the alternatives doesn't affect the pattern.