diff --git a/_specifications/lsp/3.17/specification.md b/_specifications/lsp/3.17/specification.md index 72ad301..4c9a6be 100644 --- a/_specifications/lsp/3.17/specification.md +++ b/_specifications/lsp/3.17/specification.md @@ -623,7 +623,7 @@ export interface TextDocumentSyncOptions { ### Language Features -Language Feature provide the actual smarts in the language server protocol. The are usually executed on a [text document, position] tuple. The main language feature categories are: +Language Features provide the actual smarts in the language server protocol. They are usually executed on a [text document, position] tuple. The main language feature categories are: - code comprehension features like Hover or Goto Definition. - coding features like diagnostics, code complete or code actions. @@ -690,7 +690,7 @@ Language Feature provide the actual smarts in the language server protocol. The #### Implementation Considerations -Language servers usually run in a separate process and client communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: +Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: - if a client sends a request to the server and the client state changes in a way that it invalidates the response it should do the following: - cancel the server request and ignore the result if the result is not useful for the client anymore. If necessary the client should resend the request. @@ -704,9 +704,9 @@ Servers usually support different communication channels (e.g. stdio, pipes, ... - **stdio**: uses stdio as the communication channel. - **pipe**: use pipes (Windows) or socket files (Linux, Mac) as the communication channel. The pipe / socket file name is passed as the next arg or with `--pipe=`. - **socket**: uses a socket as the communication channel. The port is passed as next arg or with `--port=`. -- **node-ipc**: use node IPC communication between the client and the server. This is only support if both client and server run under node. +- **node-ipc**: use node IPC communication between the client and the server. This is only supported if both client and server run under node. -To support the case that the editor starting a server crashes an editor should also pass its process id to the server. This allows the server to monitor the editor process and to shutdown itself if the editor process dies. The process id pass on the command line should be the same as the one passed in the initialize parameters. The command line argument to use is `--clientProcessId`. +To support the case that the editor starting a server crashes an editor should also pass its process id to the server. This allows the server to monitor the editor process and to shutdown itself if the editor process dies. The process id passed on the command line should be the same as the one passed in the initialize parameters. The command line argument to use is `--clientProcessId`. #### Meta Model @@ -732,7 +732,6 @@ Since 3.17 there is a meta model describing the LSP protocol: - server cancelable - augmentation of syntax tokens * Add support to negotiate the position encoding. -* Add support for HTML tags in markdown. * Add support for relative patterns in file watchers. * Add support for type hierarchies * Add support for inline values. diff --git a/_specifications/lsp/3.17/types/documentFilter.md b/_specifications/lsp/3.17/types/documentFilter.md index 056d71d..8aa72c6 100644 --- a/_specifications/lsp/3.17/types/documentFilter.md +++ b/_specifications/lsp/3.17/types/documentFilter.md @@ -1,6 +1,6 @@ #### DocumentFilter -A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter the applies to JSON files with name `package.json`: +A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`: ```typescript { language: 'typescript', scheme: 'file' } { language: 'json', pattern: '**/package.json' } diff --git a/_specifications/lsp/3.18/specification.md b/_specifications/lsp/3.18/specification.md index 6a11da7..d0c631f 100644 --- a/_specifications/lsp/3.18/specification.md +++ b/_specifications/lsp/3.18/specification.md @@ -620,7 +620,7 @@ export interface TextDocumentSyncOptions { ### Language Features -Language Feature provide the actual smarts in the language server protocol. The are usually executed on a [text document, position] tuple. The main language feature categories are: +Language Features provide the actual smarts in the language server protocol. They are usually executed on a [text document, position] tuple. The main language feature categories are: - code comprehension features like Hover or Goto Definition. - coding features like diagnostics, code complete or code actions. @@ -687,7 +687,7 @@ Language Feature provide the actual smarts in the language server protocol. The #### Implementation Considerations -Language servers usually run in a separate process and client communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: +Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: - if a client sends a request to the server and the client state changes in a way that it invalidates the response it should do the following: - cancel the server request and ignore the result if the result is not useful for the client anymore. If necessary the client should resend the request. @@ -701,9 +701,9 @@ Servers usually support different communication channels (e.g. stdio, pipes, ... - **stdio**: uses stdio as the communication channel. - **pipe**: use pipes (Windows) or socket files (Linux, Mac) as the communication channel. The pipe / socket file name is passed as the next arg or with `--pipe=`. - **socket**: uses a socket as the communication channel. The port is passed as next arg or with `--port=`. -- **node-ipc**: use node IPC communication between the client and the server. This is only support if both client and server run under node. +- **node-ipc**: use node IPC communication between the client and the server. This is only supported if both client and server run under node. -To support the case that the editor starting a server crashes an editor should also pass its process id to the server. This allows the server to monitor the editor process and to shutdown itself if the editor process dies. The process id pass on the command line should be the same as the one passed in the initialize parameters. The command line argument to use is `--clientProcessId`. +To support the case that the editor starting a server crashes an editor should also pass its process id to the server. This allows the server to monitor the editor process and to shutdown itself if the editor process dies. The process id passed on the command line should be the same as the one passed in the initialize parameters. The command line argument to use is `--clientProcessId`. #### Meta Model @@ -731,7 +731,6 @@ Since 3.17 there is a meta model describing the LSP protocol: - server cancelable - augmentation of syntax tokens * Add support to negotiate the position encoding. -* Add support for HTML tags in markdown. * Add support for relative patterns in file watchers. * Add support for type hierarchies * Add support for inline values. diff --git a/_specifications/lsp/3.18/types/documentFilter.md b/_specifications/lsp/3.18/types/documentFilter.md index 056d71d..8aa72c6 100644 --- a/_specifications/lsp/3.18/types/documentFilter.md +++ b/_specifications/lsp/3.18/types/documentFilter.md @@ -1,6 +1,6 @@ #### DocumentFilter -A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter the applies to JSON files with name `package.json`: +A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`: ```typescript { language: 'typescript', scheme: 'file' } { language: 'json', pattern: '**/package.json' } diff --git a/_specifications/specification-3-14.md b/_specifications/specification-3-14.md index 3e3037c..77ef2a5 100644 --- a/_specifications/specification-3-14.md +++ b/_specifications/specification-3-14.md @@ -754,7 +754,7 @@ interface TextDocumentPositionParams { #### DocumentFilter -A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter the applies to JSON files with name `package.json`: +A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`: ```typescript { language: 'typescript', scheme: 'file' } { language: 'json', pattern: '**/package.json' } @@ -4368,7 +4368,7 @@ _Registration Options_: `TextDocumentRegistrationOptions` ### Implementation considerations -Language servers usually run in a separate process and client communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: +Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: - if a client sends a request to the server and the client state changes in a way that the result will be invalid it should cancel the server request and ignore the result. If necessary it can resend the request to receive an up to date result. - if a server detects a state change that invalidates the result of a request in execution the server can error these requests with `ContentModified`. If clients receive a `ContentModified` error, it generally should not show it in the UI for the end-user. Clients can resend the request if appropriate. diff --git a/_specifications/specification-3-15.md b/_specifications/specification-3-15.md index 189236f..a6e1708 100644 --- a/_specifications/specification-3-15.md +++ b/_specifications/specification-3-15.md @@ -922,7 +922,7 @@ interface TextDocumentPositionParams { #### DocumentFilter -A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter the applies to JSON files with name `package.json`: +A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`: ```typescript { language: 'typescript', scheme: 'file' } { language: 'json', pattern: '**/package.json' } @@ -5786,7 +5786,7 @@ export interface SelectionRange { ### Implementation considerations -Language servers usually run in a separate process and client communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: +Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: - if a client sends a request to the server and the client state changes in a way that the result will be invalid it should cancel the server request and ignore the result. If necessary it can resend the request to receive an up to date result. - if a server detects a state change that invalidates the result of a request in execution the server can error these requests with `ContentModified`. If clients receive a `ContentModified` error, it generally should not show it in the UI for the end-user. Clients can resend the request if appropriate. diff --git a/_specifications/specification-3-16.md b/_specifications/specification-3-16.md index 86fc6ff..b6f93b3 100644 --- a/_specifications/specification-3-16.md +++ b/_specifications/specification-3-16.md @@ -1239,7 +1239,7 @@ interface TextDocumentPositionParams { #### DocumentFilter -A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter the applies to JSON files with name `package.json`: +A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`: ```typescript { language: 'typescript', scheme: 'file' } { language: 'json', pattern: '**/package.json' } @@ -8129,7 +8129,7 @@ Server implementations of this method should ensure that the moniker calculation ### Implementation Considerations -Language servers usually run in a separate process and client communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: +Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion. Additionally clients usually allow users to interact with the source code even if request results are pending. We recommend the following implementation pattern to avoid that clients apply outdated response results: - if a client sends a request to the server and the client state changes in a way that it invalidates the response it should do the following: - cancel the server request and ignore the result if the result is not useful for the client anymore. If necessary the client should resend the request. @@ -8144,7 +8144,7 @@ Servers usually support different communication channels (e.g. stdio, pipes, ... - **stdio**: uses stdio as the communication channel. - **pipe**: use pipes (Windows) or socket files (Linux, Mac) as the communication channel. The pipe / socket file name is passed as the next arg or with `--pipe=`. - **socket**: uses a socket as the communication channel. The port is passed as next arg or with `--port=`. -- **node-ipc**: use node IPC communication between the client and the server. This is only support if both client and server run under node. +- **node-ipc**: use node IPC communication between the client and the server. This is only supported if both client and server run under node. ### Change Log