From efd2020eb37fe46f159766323aebd4064495eac1 Mon Sep 17 00:00:00 2001 From: Ahmed Ashour Date: Mon, 23 Jan 2023 14:58:00 +0100 Subject: [PATCH] Grammar: use `an` when appropriate (#1646) --- _specifications/lsif/0.4.0/specification.md | 2 +- _specifications/lsif/0.5.0/specification.md | 4 ++-- _specifications/lsif/0.6.0/specification.md | 4 ++-- _specifications/lsp/3.17/language/documentSymbol.md | 2 +- _specifications/lsp/3.17/language/foldingRange.md | 2 +- _specifications/lsp/3.17/language/inlayHint.md | 6 +++--- _specifications/lsp/3.17/metaModel/metaModel.json | 2 +- _specifications/lsp/3.17/metaModel/metaModel.ts | 2 +- _specifications/lsp/3.17/textDocument/didRename.md | 2 +- _specifications/lsp/3.18/language/documentSymbol.md | 2 +- _specifications/lsp/3.18/language/foldingRange.md | 2 +- _specifications/lsp/3.18/language/inlayHint.md | 6 +++--- _specifications/lsp/3.18/language/pullDiagnostics.md | 2 +- _specifications/lsp/3.18/metaModel/metaModel.json | 2 +- _specifications/lsp/3.18/metaModel/metaModel.schema.json | 2 +- _specifications/lsp/3.18/metaModel/metaModel.ts | 2 +- _specifications/lsp/3.18/textDocument/didRename.md | 2 +- _specifications/specification-3-14.md | 6 +++--- _specifications/specification-3-15.md | 4 ++-- _specifications/specification-3-16.md | 6 +++--- 20 files changed, 31 insertions(+), 31 deletions(-) diff --git a/_specifications/lsif/0.4.0/specification.md b/_specifications/lsif/0.4.0/specification.md index 30a1ed9..5804385 100644 --- a/_specifications/lsif/0.4.0/specification.md +++ b/_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. ### Request: `textDocument/declaration` diff --git a/_specifications/lsif/0.5.0/specification.md b/_specifications/lsif/0.5.0/specification.md index 35297d7..14bc87c 100644 --- a/_specifications/lsif/0.5.0/specification.md +++ b/_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. ### Request: `textDocument/declaration` @@ -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", diff --git a/_specifications/lsif/0.6.0/specification.md b/_specifications/lsif/0.6.0/specification.md index 50bfadd..28da651 100644 --- a/_specifications/lsif/0.6.0/specification.md +++ b/_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. ### Request: `textDocument/declaration` @@ -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) ## Additional Information diff --git a/_specifications/lsp/3.17/language/documentSymbol.md b/_specifications/lsp/3.17/language/documentSymbol.md index 5e28907..d4caaf9 100644 --- a/_specifications/lsp/3.17/language/documentSymbol.md +++ b/_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. */ diff --git a/_specifications/lsp/3.17/language/foldingRange.md b/_specifications/lsp/3.17/language/foldingRange.md index 7d2d754..dd37b9d 100644 --- a/_specifications/lsp/3.17/language/foldingRange.md +++ b/_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'; diff --git a/_specifications/lsp/3.17/language/inlayHint.md b/_specifications/lsp/3.17/language/inlayHint.md index 739b7a9..162330e 100644 --- a/_specifications/lsp/3.17/language/inlayHint.md +++ b/_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 diff --git a/_specifications/lsp/3.17/metaModel/metaModel.json b/_specifications/lsp/3.17/metaModel/metaModel.json index 52f71da..bca7c25 100644 --- a/_specifications/lsp/3.17/metaModel/metaModel.json +++ b/_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", diff --git a/_specifications/lsp/3.17/metaModel/metaModel.ts b/_specifications/lsp/3.17/metaModel/metaModel.ts index d8d5258..c50feca 100644 --- a/_specifications/lsp/3.17/metaModel/metaModel.ts +++ b/_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 = { diff --git a/_specifications/lsp/3.17/textDocument/didRename.md b/_specifications/lsp/3.17/textDocument/didRename.md index e7f4153..1dc986d 100644 --- a/_specifications/lsp/3.17/textDocument/didRename.md +++ b/_specifications/lsp/3.17/textDocument/didRename.md @@ -1,5 +1,5 @@ #### Renaming a document -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. diff --git a/_specifications/lsp/3.18/language/documentSymbol.md b/_specifications/lsp/3.18/language/documentSymbol.md index 5e28907..d4caaf9 100644 --- a/_specifications/lsp/3.18/language/documentSymbol.md +++ b/_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. */ diff --git a/_specifications/lsp/3.18/language/foldingRange.md b/_specifications/lsp/3.18/language/foldingRange.md index 7d2d754..dd37b9d 100644 --- a/_specifications/lsp/3.18/language/foldingRange.md +++ b/_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'; diff --git a/_specifications/lsp/3.18/language/inlayHint.md b/_specifications/lsp/3.18/language/inlayHint.md index 2e38cae..d1e7c96 100644 --- a/_specifications/lsp/3.18/language/inlayHint.md +++ b/_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 diff --git a/_specifications/lsp/3.18/language/pullDiagnostics.md b/_specifications/lsp/3.18/language/pullDiagnostics.md index a68d3be..837cc26 100644 --- a/_specifications/lsp/3.18/language/pullDiagnostics.md +++ b/_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. * diff --git a/_specifications/lsp/3.18/metaModel/metaModel.json b/_specifications/lsp/3.18/metaModel/metaModel.json index f8ef038..673f117 100644 --- a/_specifications/lsp/3.18/metaModel/metaModel.json +++ b/_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", diff --git a/_specifications/lsp/3.18/metaModel/metaModel.schema.json b/_specifications/lsp/3.18/metaModel/metaModel.schema.json index f50cf37..2d8f47d 100644 --- a/_specifications/lsp/3.18/metaModel/metaModel.schema.json +++ b/_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.", diff --git a/_specifications/lsp/3.18/metaModel/metaModel.ts b/_specifications/lsp/3.18/metaModel/metaModel.ts index d8d5258..c50feca 100644 --- a/_specifications/lsp/3.18/metaModel/metaModel.ts +++ b/_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 = { diff --git a/_specifications/lsp/3.18/textDocument/didRename.md b/_specifications/lsp/3.18/textDocument/didRename.md index e7f4153..1dc986d 100644 --- a/_specifications/lsp/3.18/textDocument/didRename.md +++ b/_specifications/lsp/3.18/textDocument/didRename.md @@ -1,5 +1,5 @@ #### Renaming a document -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. diff --git a/_specifications/specification-3-14.md b/_specifications/specification-3-14.md index bc02d46..64c662c 100644 --- a/_specifications/specification-3-14.md +++ b/_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', /** diff --git a/_specifications/specification-3-15.md b/_specifications/specification-3-15.md index 657b8ff..dce65e0 100644 --- a/_specifications/specification-3-15.md +++ b/_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', /** diff --git a/_specifications/specification-3-16.md b/_specifications/specification-3-16.md index 133503c..3cb2737 100644 --- a/_specifications/specification-3-16.md +++ b/_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. #### Text Documents @@ -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', /**