diff options
| -rw-r--r-- | runtime/doc/lsp.txt | 228 | ||||
| -rw-r--r-- | runtime/doc/vim_diff.txt | 22 | ||||
| -rw-r--r-- | scripts/gen_help_html.lua | 1 |
3 files changed, 89 insertions, 162 deletions
diff --git a/runtime/doc/lsp.txt b/runtime/doc/lsp.txt index 2a781119cf..62b280e7f6 100644 --- a/runtime/doc/lsp.txt +++ b/runtime/doc/lsp.txt @@ -24,26 +24,23 @@ QUICKSTART *lsp-quickstart* Nvim provides an LSP client, but the servers are provided by third parties. Follow these steps to get LSP features: - 1. Install language servers using your package manager or by - following the upstream installation instruction. +1. Install language servers using your package manager or by following the + upstream installation instruction. You can find language servers here: + https://microsoft.github.io/language-server-protocol/implementors/servers/ - A list of language servers is available at: +2. Configure the LSP client per language server. See |vim.lsp.start()| or use + this minimal example as a guide: >lua - https://microsoft.github.io/language-server-protocol/implementors/servers/ - - 2. Configure the LSP client per language server. - A minimal example: ->lua vim.lsp.start({ name = 'my-server-name', cmd = {'name-of-language-server-executable'}, root_dir = vim.fs.dirname(vim.fs.find({'setup.py', 'pyproject.toml'}, { upward = true })[1]), }) < - See |vim.lsp.start()| for details. +3. Check that the server attached to the buffer: > + :lua =vim.lsp.get_active_clients() - 3. Configure keymaps and autocmds to utilize LSP features. - See |lsp-config|. +4. Configure keymaps and autocmds to use LSP features. See |lsp-config|. *lsp-config* *lsp-defaults* @@ -103,11 +100,9 @@ calls behind capability checks: < To learn what capabilities are available you can run the following command in -a buffer with a started LSP client: +a buffer with a started LSP client: >vim ->vim :lua =vim.lsp.get_active_clients()[1].server_capabilities -< Full list of features provided by default can be found in |lsp-buf|. @@ -115,26 +110,20 @@ Full list of features provided by default can be found in |lsp-buf|. FAQ *lsp-faq* - Q: How to force-reload LSP? - A: Stop all clients, then reload the buffer. >vim - +- A: Stop all clients, then reload the buffer. >vim :lua vim.lsp.stop_client(vim.lsp.get_active_clients()) :edit - Q: Why isn't completion working? - A: In the buffer where you want to use LSP, check that 'omnifunc' is set to - "v:lua.vim.lsp.omnifunc": >vim - - :verbose set omnifunc? - -< Some other plugin may be overriding the option. To avoid that, you could - set the option in an |after-directory| ftplugin, e.g. - "after/ftplugin/python.vim". +- A: In the buffer where you want to use LSP, check that 'omnifunc' is set to + "v:lua.vim.lsp.omnifunc": `:verbose set omnifunc?` + - Some other plugin may be overriding the option. To avoid that you could + set the option in an |after-directory| ftplugin, e.g. + "after/ftplugin/python.vim". - Q: How do I run a request synchronously (e.g. for formatting on file save)? - A: Check if the function has an `async` parameter and set the value to - false. - - E.g. code formatting: >vim +- A: Check if the function has an `async` parameter and set the value to + false. E.g. code formatting: >vim " Auto-format *.rs (rust) files prior to saving them " (async = false is the default for format) @@ -142,7 +131,7 @@ FAQ *lsp-faq* < *lsp-vs-treesitter* - Q: How do LSP and Treesitter compare? - A: LSP requires a client and language server. The language server uses +- A: LSP requires a client and language server. The language server uses semantic analysis to understand code at a project level. This provides language servers with the ability to rename across files, find definitions in external libraries and more. @@ -173,129 +162,72 @@ when creating a new client. Keys are LSP method names: >vim *lsp-method* Methods are the names of requests and notifications as defined by the LSP -specification. These LSP requests/notifications are defined by default: - - callHierarchy/incomingCalls - callHierarchy/outgoingCalls - textDocument/codeAction - textDocument/completion - textDocument/declaration* - textDocument/definition - textDocument/documentHighlight - textDocument/documentSymbol - textDocument/formatting - textDocument/hover - textDocument/implementation* - textDocument/inlayHint - textDocument/publishDiagnostics - textDocument/rangeFormatting - textDocument/references - textDocument/rename - textDocument/semanticTokens/full - textDocument/semanticTokens/full/delta - textDocument/signatureHelp - textDocument/typeDefinition* - window/logMessage - window/showMessage - window/showDocument - window/showMessageRequest - workspace/applyEdit - workspace/inlayHint/refresh - workspace/symbol - -* NOTE: These are sometimes not implemented by servers. +specification. These LSP requests/notifications are defined by default in the +Nvim LSP client (but depends on server support): + +- callHierarchy/incomingCalls +- callHierarchy/outgoingCalls +- textDocument/codeAction +- textDocument/completion +- textDocument/declaration* +- textDocument/definition +- textDocument/documentHighlight +- textDocument/documentSymbol +- textDocument/formatting +- textDocument/hover +- textDocument/implementation* +- textDocument/inlayHint +- textDocument/publishDiagnostics +- textDocument/rangeFormatting +- textDocument/references +- textDocument/rename +- textDocument/semanticTokens/full +- textDocument/semanticTokens/full/delta +- textDocument/signatureHelp +- textDocument/typeDefinition* +- window/logMessage +- window/showMessage +- window/showDocument +- window/showMessageRequest +- workspace/applyEdit +- workspace/inlayHint/refresh +- workspace/symbol *lsp-handler* +LSP handlers are functions that handle |lsp-response|s to requests made by Nvim +to the server. (Notifications, as opposed to requests, are fire-and-forget: +there is no response, so they can't be handled. |lsp-notification|) -LSP handlers are functions with signatures designed to handle LSP responses -and notifications. - -For |lsp-response|, each |lsp-handler| has this signature: > - - function(err, result, ctx, config) -< - Parameters: ~ - {err} (table|nil) - When the language server is unable to complete a - request, a table with information about the error is - sent. Otherwise, it is `nil`. See |lsp-response|. - {result} (Result | Params | nil) - When the language server is able to successfully - complete a request, this contains the `result` key of - the response. See |lsp-response|. - {ctx} (table) - Context describes additional calling state associated - with the handler. It consists of the following key, - value pairs: - - {method} (string) - The |lsp-method| name. - {client_id} (number) - The ID of the |vim.lsp.client|. - {bufnr} (Buffer) - Buffer handle, or 0 for current. - {params} (table|nil) - The parameters used in the original - request which resulted in this handler - call. - {version} (number) Document version at time of - request. Handlers can compare this to the - current document version to check if the - response is "stale". - See also |b:changedtick|. - {config} (table) - Configuration for the handler. - - Each handler can define its own configuration table - that allows users to customize the behavior of a - particular handler. - - To configure a particular |lsp-handler|, see: - |lsp-handler-configuration| - - - Returns: ~ - The |lsp-handler| can respond by returning two values: `result, err` - Where `err` must be shaped like an RPC error: - `{ code, message, data? }` - - You can use |vim.lsp.rpc.rpc_response_error()| to create this object. - -For |lsp-notification|, each |lsp-handler| has this signature: > +Each response handler has this signature: > - function(err, result, ctx, config) + function(err, result, ctx, config) < Parameters: ~ - {err} (nil) - This is always `nil`. - See |lsp-notification| - {result} (Result) - This contains the `params` key of the notification. - See |lsp-notification| - {ctx} (table) - Context describes additional calling state associated - with the handler. It consists of the following key, - value pairs: - - {method} (string) - The |lsp-method| name. - {client_id} (number) - The ID of the |vim.lsp.client|. - {config} (table) - Configuration for the handler. - - Each handler can define its own configuration table - that allows users to customize the behavior of a - particular handler. - - For an example, see: - |vim.lsp.diagnostic.on_publish_diagnostics()| - - To configure a particular |lsp-handler|, see: - |lsp-handler-configuration| + - {err} (table|nil) Error info dict, or `nil` if the request + completed. + - {result} (Result | Params | nil) `result` key of the |lsp-response| or + `nil` if the request failed. + - {ctx} (table) Table of calling state associated with the + handler, with these keys: + - {method} (string) |lsp-method| name. + - {client_id} (number) |vim.lsp.client| identifier. + - {bufnr} (Buffer) Buffer handle. + - {params} (table|nil) Request parameters table. + - {version} (number) Document version at time of + request. Handlers can compare this to the + current document version to check if the + response is "stale". See also |b:changedtick|. + - {config} (table) Handler-defined configuration table, which allows + users to customize handler behavior. + For an example, see: + |vim.lsp.diagnostic.on_publish_diagnostics()| + To configure a particular |lsp-handler|, see: + |lsp-handler-configuration| Returns: ~ - The |lsp-handler|'s return value will be ignored. + Two values `result, err` where `err` is shaped like an RPC error: > + { code, message, data? } +< You can use |vim.lsp.rpc.rpc_response_error()| to create this object. *lsp-handler-configuration* @@ -419,12 +351,12 @@ name: >lua < *lsp-response* -For the format of the response message, see: - https://microsoft.github.io/language-server-protocol/specifications/specification-current/#responseMessage +LSP response shape: +https://microsoft.github.io/language-server-protocol/specifications/specification-current/#responseMessage *lsp-notification* -For the format of the notification message, see: - https://microsoft.github.io/language-server-protocol/specifications/specification-current/#notificationMessage +LSP notification shape: +https://microsoft.github.io/language-server-protocol/specifications/specification-current/#notificationMessage *lsp-on-list-handler* diff --git a/runtime/doc/vim_diff.txt b/runtime/doc/vim_diff.txt index ff3e19689b..f07fb0902e 100644 --- a/runtime/doc/vim_diff.txt +++ b/runtime/doc/vim_diff.txt @@ -564,7 +564,8 @@ Aliases: Commands: :behave :fixdel - :hardcopy + *hardcopy* `:hardcopy` was removed. Instead, use `:TOhtml` and print the + resulting HTML using a web browser or other HTML viewer. :helpfind :mode (no longer accepts an argument) :open @@ -586,6 +587,11 @@ Compile-time features: Emacs tags support X11 integration (see |x11-selection|) +Cscope: + *cscope* + Cscope support was removed in favour of plugin-based solutions such as: + https://github.com/dhananjaylatkar/cscope_maps.nvim + Eval: Vim9script *cscope_connection()* @@ -715,6 +721,7 @@ Plugins: - logiPat - rrhelper +- *vimball* Providers: @@ -771,18 +778,5 @@ TUI: at how the terminal is sending CSI. Nvim does not issue such a sequence and always uses 7-bit control sequences. -Cscope: - *cscope* - Cscope support was removed in favour of plugin-based solutions such as: - https://github.com/dhananjaylatkar/cscope_maps.nvim - -Hardcopy: - *hardcopy* - `:hardcopy` was removed. Instead, use `:TOhtml` and print the resulting HTML - using a web browser or some other HTML viewer. - -Bundled plugins: - vimball *vimball* - ============================================================================== vim:tw=78:ts=8:sw=2:et:ft=help:norl: diff --git a/scripts/gen_help_html.lua b/scripts/gen_help_html.lua index 6cdf028f5c..43c0e135d4 100644 --- a/scripts/gen_help_html.lua +++ b/scripts/gen_help_html.lua @@ -43,6 +43,7 @@ local M = {} -- All other files are "legacy" files which require fixed-width layout. local new_layout = { ['api.txt'] = true, + ['lsp.txt'] = true, ['channel.txt'] = true, ['deprecated.txt'] = true, ['develop.txt'] = true, |