Minor grammar and punctuation fixes in regexp.md (#1794)

_specifications/lsp/3.18/types/regexp.md

@@ -1,9 +1,9 @@
 #### <a href="#regExp" name="regExp" class="anchor"> Regular Expressions </a>
 
-Regular expression are a powerful tool and there are actual use cases for them in the language server protocol. However the downside with them is that almost every programming language has its own set of regular expression features so the specification can not simply refer to them as a regular expression. So the LSP uses a two step approach to support regular expressions:
+Regular expressions are a powerful tool and there are actual use cases for them in the language server protocol. However the downside with them is that almost every programming language has its own set of regular expression features so the specification can not simply refer to them as a regular expression. So the LSP uses a two step approach to support regular expressions:
 
-* the client will announce which regular expression engine it will use. This will allow server that are written for a very specific client make full use of the regular expression capabilities of the client
-* the specification will define a set of regular expression features that should be supported by a client. Instead of writing a new specification LSP will refer to the [ECMAScript Regular Expression specification](https://tc39.es/ecma262/#sec-regexp-regular-expression-objects) and remove features from it that are not necessary in the context of LSP or hard to implement for other clients.
+* The client will announce which regular expression engine it will use. This will allow servers that are written for a very specific client to make full use of the regular expression capabilities of that client.
+* The specification will define a set of regular expression features that should be supported by a client. Instead of writing a new specification LSP will refer to the [ECMAScript Regular Expression specification](https://tc39.es/ecma262/#sec-regexp-regular-expression-objects) and remove features from it that are not necessary in the context of LSP or are hard to implement for other clients.
 
 _Client Capability_:
 
@@ -29,7 +29,7 @@ export interface RegularExpressionsClientCapabilities {
 }
 ```
 
-The following table lists the well known engine values. Please note that the table should be driven by the community which integrates LSP into existing clients. It is not the goal of the spec to list all available regular expression engines.
+The following table lists the well known engine values. Please note that the table should be driven by the community which integrates the LSP into existing clients. It is not the goal of the spec to list all available regular expression engines.
 
 Engine | Version | Documentation
 ------- | ------- | -------------
@@ -39,9 +39,9 @@ _Regular Expression Subset_:
 
 The following features from the [ECMAScript 2020](https://tc39.es/ecma262/#sec-regexp-regular-expression-objects) regular expression specification are NOT mandatory for a client:
 
-- *Assertions*: Lookahead assertion, Negative lookahead assertion, lookbehind assertion, negative lookbehind assertion.
+- *Assertions*: lookahead assertion, negative lookahead assertion, lookbehind assertion, negative lookbehind assertion.
 - *Character classes*: matching control characters using caret notation (e.g. `\cX`) and matching UTF-16 code units (e.g. `\uhhhh`).
 - *Group and ranges*: named capturing groups.
-- *Unicode property escapes*: none of the features needs to be supported.
+- *Unicode property escapes*: none of the features need to be supported.
 
-The only regular expression flag that a client needs to support is 'i' to specify a case insensitive search.
+The only regular expression flag that a client needs to support is `i` to specify a case insensitive search.