Grammar: use an when appropriate (#1646)

_specifications/lsif/0.4.0/specification.md

@@ -241,7 +241,7 @@ Running **Go to Definition** on `X` in `let x: X` will show a dialog which lets
 { id : 40, type: "edge", label: "item", outV: 38, inVs: [9, 13], document: 4 }
 ```
 
-The `item` edge as an additional property document which indicate in which document these declaration are. We added this information to still make it easy to emit the data but also make it easy to process the data to store it in a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. a item edge and only refer to a range that got already added to a document using a `containes` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `document` property looks like a fair balance.
+The `item` edge as an additional property document which indicate in which document these declaration are. We added this information to still make it easy to emit the data but also make it easy to process the data to store it in a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. an item edge and only refer to a range that got already added to a document using a `containes` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `document` property looks like a fair balance.
 
 ### <a href="#declaration" name="declaration" class="anchor">Request: `textDocument/declaration`</a>
 

_specifications/lsif/0.5.0/specification.md

@@ -287,7 +287,7 @@ Running **Go to Definition** on `X` in `let x: X` will show a dialog which lets
 { id : 40, type: "edge", label: "item", outV: 38, inVs: [9, 13], shard: 4 }
 ```
 
-The `item` edge as an additional property shard which indicate the vertex that is the source (e.g. a document or a project) of these declarations. We added this information to still make it easy to emit the data but also make it easy to process and shard the data when storing into a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. a item edge and only refer to a range that got already added to a document using a `contains` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `shard` property looks like a fair balance.
+The `item` edge as an additional property shard which indicate the vertex that is the source (e.g. a document or a project) of these declarations. We added this information to still make it easy to emit the data but also make it easy to process and shard the data when storing into a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. an item edge and only refer to a range that got already added to a document using a `contains` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `shard` property looks like a fair balance.
 
 ### <a href="#declaration" name="declaration" class="anchor">Request: `textDocument/declaration`</a>
 
@@ -1140,7 +1140,7 @@ w.dispose();
 
 Now if a user search for reference to `Widget#dispose` it is expected that the reference `d.dispose` in P1 is included in the result. However when P1 is process the tools doesn't know about P2. And when P2 is processed it usually doesn't know about the source of P1. It only knows about its API shape (e.g. in TypeScript the corresponding `d.ts` file).
 
-To make this work we first need to group projects into larger units so that we know in which projects `d.dispose` is actually a match. Assume there is a totally unrelated project PX which also uses `Disposable` from P1 but P2 is never linked into one system with PX. So a object of type `Widget` can never flow to code in PX hence reference in PX should not be listed. We therefore introduce the notation of a group to logically group projects into larger systems. Projects belong to a group and groups are identified using a URI. Lets look at the concrete dumps for P1 and P2:
+To make this work we first need to group projects into larger units so that we know in which projects `d.dispose` is actually a match. Assume there is a totally unrelated project PX which also uses `Disposable` from P1 but P2 is never linked into one system with PX. So an object of type `Widget` can never flow to code in PX hence reference in PX should not be listed. We therefore introduce the notation of a group to logically group projects into larger systems. Projects belong to a group and groups are identified using a URI. Lets look at the concrete dumps for P1 and P2:
 
 ```typescript
 {id: 2, type: "vertex", label: "group",

_specifications/lsif/0.6.0/specification.md

@@ -291,7 +291,7 @@ Running **Go to Definition** on `X` in `let x: X` will show a dialog which lets
 { id : 40, type: "edge", label: "item", outV: 38, inVs: [9, 13], shard: 4 }
 ```
 
-The `item` edge as an additional property shard which indicate the vertex that is the source (e.g. a document or a project) of these declarations. We added this information to still make it easy to emit the data but also make it easy to process and shard the data when storing into a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. a item edge and only refer to a range that got already added to a document using a `contains` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `shard` property looks like a fair balance.
+The `item` edge as an additional property shard which indicate the vertex that is the source (e.g. a document or a project) of these declarations. We added this information to still make it easy to emit the data but also make it easy to process and shard the data when storing into a database. Without that information we would either need to specific an order in which data needs to be emitted (e.g. an item edge and only refer to a range that got already added to a document using a `contains` edge) or we force processing tools to keep a lot of vertices and edges in memory. The approach of having this `shard` property looks like a fair balance.
 
 ### <a href="#declaration" name="declaration" class="anchor">Request: `textDocument/declaration`</a>
 
@@ -1481,7 +1481,7 @@ The following emitting constraints (some of which have already been mentioned in
 - a `resultRange` can not be used as a target in a `contains` edge.
 - after a document end event has been emitted only result sets, reference or implementation results emitted through that document can be referenced in edges. It is, for example, not allowed to reference ranges or result ranges from that document. This also includes adding monikers to ranges or result sets. The document data so to speak can not be altered anymore.
 - if ranges point to result sets and monikers are emitted, they must be emitted on the result set and can't be emitted on individual ranges.
-- if a range is references in a items edge the range must have been attached to a document using the contains edge. This ensures that that target document of a range is known. (@since 0.6.0)
+- if a range is references in items edge the range must have been attached to a document using the contains edge. This ensures that that target document of a range is known. (@since 0.6.0)
 
 ## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information </a>
 

_specifications/lsp/3.17/language/documentSymbol.md

@@ -275,7 +275,7 @@ export interface SymbolInformation {
 	 * the range usually spans more then the actual symbol's name and does
 	 * normally include things like visibility modifiers.
 	 *
-	 * The range doesn't have to denote a node range in the sense of a abstract
+	 * The range doesn't have to denote a node range in the sense of an abstract
 	 * syntax tree. It can therefore not be used to re-construct a hierarchy of
 	 * the symbols.
 	 */

_specifications/lsp/3.17/language/foldingRange.md

@@ -120,7 +120,7 @@ export namespace FoldingRangeKind {
 	export const Comment = 'comment';
 
 	/**
-	 * Folding range for a imports or includes
+	 * Folding range for imports or includes
 	 */
 	export const Imports = 'imports';
 

_specifications/lsp/3.17/language/inlayHint.md

@@ -24,7 +24,7 @@ export interface InlayHintClientCapabilities {
 	dynamicRegistration?: boolean;
 
 	/**
-	 * Indicates which properties a client can resolve lazily on a inlay
+	 * Indicates which properties a client can resolve lazily on an inlay
 	 * hint.
 	 */
 	resolveSupport?: {
@@ -170,7 +170,7 @@ export interface InlayHint {
 
 
 	/**
-	 * A data entry field that is preserved on a inlay hint between
+	 * A data entry field that is preserved on an inlay hint between
 	 * a `textDocument/inlayHint` and a `inlayHint/resolve` request.
 	 */
 	data?: LSPAny;
@@ -256,7 +256,7 @@ export type InlayHintKind = 1 | 2;
 > *Since version 3.17.0*
 
 The request is sent from the client to the server to resolve additional information for a given inlay hint. This is usually used to compute
-the `tooltip`, `location` or `command` properties of a inlay hint's label part to avoid its unnecessary computation during the `textDocument/inlayHint` request.
+the `tooltip`, `location` or `command` properties of an inlay hint's label part to avoid its unnecessary computation during the `textDocument/inlayHint` request.
 
 Consider the clients announces the `label.location` property as a property that can be resolved lazy using the client capability
 

_specifications/lsp/3.17/metaModel/metaModel.json

@@ -6002,7 +6002,7 @@
 					"documentation": "The edits to apply."
 				}
 			],
-			"documentation": "The parameters passed via a apply workspace edit request."
+			"documentation": "The parameters passed via an apply workspace edit request."
 		},
 		{
 			"name": "ApplyWorkspaceEditResult",

_specifications/lsp/3.17/metaModel/metaModel.ts

@@ -346,7 +346,7 @@ export type Structure = {
 };
 
 /**
- * Defines a unnamed structure of an object literal.
+ * Defines an unnamed structure of an object literal.
  */
 export type StructureLiteral = {
 

_specifications/lsp/3.17/textDocument/didRename.md

@@ -1,5 +1,5 @@
 #### <a href="#textDocument_didRename" name="textDocument_didRename" class="anchor">Renaming a document</a>
 
-Document renames should be signaled to a server sending a document close notification with the document's old name followed by a open notification using the document's new name. Major reason is that besides the name other attributes can change as well like the language that is associated with the document. In addition the new document could not be of interest for the server anymore.
+Document renames should be signaled to a server sending a document close notification with the document's old name followed by an open notification using the document's new name. Major reason is that besides the name other attributes can change as well like the language that is associated with the document. In addition the new document could not be of interest for the server anymore.
 
 Servers can participate in a document rename by subscribing for the [`workspace/didRenameFiles`](#workspace_didRenameFiles) notification or the [`workspace/willRenameFiles`](#workspace_willRenameFiles) request.

_specifications/lsp/3.18/language/documentSymbol.md

@@ -275,7 +275,7 @@ export interface SymbolInformation {
 	 * the range usually spans more then the actual symbol's name and does
 	 * normally include things like visibility modifiers.
 	 *
-	 * The range doesn't have to denote a node range in the sense of a abstract
+	 * The range doesn't have to denote a node range in the sense of an abstract
 	 * syntax tree. It can therefore not be used to re-construct a hierarchy of
 	 * the symbols.
 	 */

_specifications/lsp/3.18/language/foldingRange.md

@@ -120,7 +120,7 @@ export namespace FoldingRangeKind {
 	export const Comment = 'comment';
 
 	/**
-	 * Folding range for a imports or includes
+	 * Folding range for imports or includes
 	 */
 	export const Imports = 'imports';
 

_specifications/lsp/3.18/language/inlayHint.md

@@ -24,7 +24,7 @@ export interface InlayHintClientCapabilities {
 	dynamicRegistration?: boolean;
 
 	/**
-	 * Indicates which properties a client can resolve lazily on a inlay
+	 * Indicates which properties a client can resolve lazily on an inlay
 	 * hint.
 	 */
 	resolveSupport?: {
@@ -170,7 +170,7 @@ export interface InlayHint {
 
 
 	/**
-	 * A data entry field that is preserved on a inlay hint between
+	 * A data entry field that is preserved on an inlay hint between
 	 * a `textDocument/inlayHint` and a `inlayHint/resolve` request.
 	 */
 	data?: LSPAny;
@@ -256,7 +256,7 @@ export type InlayHintKind = 1 | 2;
 > *Since version 3.17.0*
 
 The request is sent from the client to the server to resolve additional information for a given inlay hint. This is usually used to compute
-the `tooltip`, `location` or `command` properties of a inlay hint's label part to avoid its unnecessary computation during the `textDocument/inlayHint` request.
+the `tooltip`, `location` or `command` properties of an inlay hint's label part to avoid its unnecessary computation during the `textDocument/inlayHint` request.
 
 Consider the clients announces the `label.location` property as a property that can be resolved lazy using the client capability
 

_specifications/lsp/3.18/language/pullDiagnostics.md

@@ -127,7 +127,7 @@ _Response_:
 /**
  * The result of a document diagnostic pull request. A report can
  * either be a full report containing all diagnostics for the
- * requested document or a unchanged report indicating that nothing
+ * requested document or an unchanged report indicating that nothing
  * has changed in terms of diagnostics in comparison to the last
  * pull request.
  *

_specifications/lsp/3.18/metaModel/metaModel.json

@@ -6002,7 +6002,7 @@
 					"documentation": "The edits to apply."
 				}
 			],
-			"documentation": "The parameters passed via a apply workspace edit request."
+			"documentation": "The parameters passed via an apply workspace edit request."
 		},
 		{
 			"name": "ApplyWorkspaceEditResult",

_specifications/lsp/3.18/metaModel/metaModel.schema.json

@@ -621,7 +621,7 @@
     },
     "StructureLiteral": {
       "additionalProperties": false,
-      "description": "Defines a unnamed structure of an object literal.",
+      "description": "Defines an unnamed structure of an object literal.",
       "properties": {
         "deprecated": {
           "description": "Whether the literal is deprecated or not. If deprecated the property contains the deprecation message.",

_specifications/lsp/3.18/metaModel/metaModel.ts

@@ -346,7 +346,7 @@ export type Structure = {
 };
 
 /**
- * Defines a unnamed structure of an object literal.
+ * Defines an unnamed structure of an object literal.
  */
 export type StructureLiteral = {
 

_specifications/lsp/3.18/textDocument/didRename.md

@@ -1,5 +1,5 @@
 #### <a href="#textDocument_didRename" name="textDocument_didRename" class="anchor">Renaming a document</a>
 
-Document renames should be signaled to a server sending a document close notification with the document's old name followed by a open notification using the document's new name. Major reason is that besides the name other attributes can change as well like the language that is associated with the document. In addition the new document could not be of interest for the server anymore.
+Document renames should be signaled to a server sending a document close notification with the document's old name followed by an open notification using the document's new name. Major reason is that besides the name other attributes can change as well like the language that is associated with the document. In addition the new document could not be of interest for the server anymore.
 
 Servers can participate in a document rename by subscribing for the [`workspace/didRenameFiles`](#workspace_didRenameFiles) notification or the [`workspace/willRenameFiles`](#workspace_willRenameFiles) request.

_specifications/specification-3-14.md

@@ -1902,7 +1902,7 @@ interface ServerCapabilities {
 			* Whether the server wants to receive workspace folder
 			* change notifications.
 			*
-			* If a strings is provided the string is treated as a ID
+			* If a strings is provided the string is treated as an ID
 			* under which the notification is registered on the client
 			* side. The ID can be used to unregister for these events
 			* using the `client/unregisterCapability` request.
@@ -3616,7 +3616,7 @@ interface SymbolInformation {
 	 * the range usually spans more then the actual symbol's name and does
 	 * normally include things like visibility modifiers.
 	 *
-	 * The range doesn't have to denote a node range in the sense of a abstract
+	 * The range doesn't have to denote a node range in the sense of an abstract
 	 * syntax tree. It can therefore not be used to re-construct a hierarchy of
 	 * the symbols.
 	 */
@@ -4318,7 +4318,7 @@ export enum FoldingRangeKind {
 	 */
 	Comment = 'comment',
 	/**
-	 * Folding range for a imports or includes
+	 * Folding range for imports or includes
 	 */
 	Imports = 'imports',
 	/**

_specifications/specification-3-15.md

@@ -4596,7 +4596,7 @@ export interface SymbolInformation {
 	 * the range usually spans more then the actual symbol's name and does
 	 * normally include things like visibility modifiers.
 	 *
-	 * The range doesn't have to denote a node range in the sense of a abstract
+	 * The range doesn't have to denote a node range in the sense of an abstract
 	 * syntax tree. It can therefore not be used to re-construct a hierarchy of
 	 * the symbols.
 	 */
@@ -5648,7 +5648,7 @@ export enum FoldingRangeKind {
 	 */
 	Comment = 'comment',
 	/**
-	 * Folding range for a imports or includes
+	 * Folding range for imports or includes
 	 */
 	Imports = 'imports',
 	/**

_specifications/specification-3-16.md

@@ -392,7 +392,7 @@ The only regular expression flag that a client needs to support is 'i' to specif
 
 The protocol supports two kind of enumerations: (a) integer based enumerations and (b) strings based enumerations. Integer based enumerations usually start with `1`. The ones that don't are historical and they were kept to stay backwards compatible. If appropriate the value set of an enumeration is announced by the defining side (e.g. client or server) and transmitted to the other side during the initialize handshake. An example is the `CompletionItemKind` enumeration. It is announced by the client using the `textDocument.completion.completionItemKind` client property.
 
-To support the evolution of enumerations the using side of an enumeration shouldn't fail on a enumeration value it doesn't know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips. Lets look at the `CompletionItemKind` enumeration as an example again: if in a future version of the specification an additional completion item kind with the value `n` gets added and announced by a client a (older) server not knowing about the value should not fail but simply ignore the value as a usable item kind.
+To support the evolution of enumerations the using side of an enumeration shouldn't fail on an enumeration value it doesn't know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips. Lets look at the `CompletionItemKind` enumeration as an example again: if in a future version of the specification an additional completion item kind with the value `n` gets added and announced by a client a (older) server not knowing about the value should not fail but simply ignore the value as a usable item kind.
 
 #### <a href="#textDocuments" name="textDocuments" class="anchor"> Text Documents </a>
 
@@ -5879,7 +5879,7 @@ export interface SymbolInformation {
 	 * the range usually spans more then the actual symbol's name and does
 	 * normally include things like visibility modifiers.
 	 *
-	 * The range doesn't have to denote a node range in the sense of a abstract
+	 * The range doesn't have to denote a node range in the sense of an abstract
 	 * syntax tree. It can therefore not be used to re-construct a hierarchy of
 	 * the symbols.
 	 */
@@ -7116,7 +7116,7 @@ export enum FoldingRangeKind {
 	 */
 	Comment = 'comment',
 	/**
-	 * Folding range for a imports or includes
+	 * Folding range for imports or includes
 	 */
 	Imports = 'imports',
 	/**