refactor(lsp): resolve the config-client entanglement

Previously the LSP-Client object contained some fields that are also
in the client config, but for a lot of other fields, the config was used
directly making the two objects vaguely entangled with either not having
a clear role.

Now the config object is treated purely as config (read-only) from the
client, and any fields the client needs from the config are now copied
in as additional fields.

This means:
- the config object is no longet normalised and is left as the user
  provided it.
- the client only reads the config on creation of the client and all
  other implementations now read the clients version of the fields.

In addition, internal support for multiple callbacks has been added to
the client so the client tracking logic (done in lua.lsp) can be done
more robustly instead of wrapping the user callbacks which may error.

1 files changed, 10 insertions, 2 deletions

diff --git a/runtime/doc/lsp.txt b/runtime/doc/lsp.txt
index fc4c164ea0..56d7b98a3c 100644
--- a/runtime/doc/lsp.txt
+++ b/runtime/doc/lsp.txt
@@ -763,6 +763,10 @@ client()                                                      *vim.lsp.client*
         before text is sent to the server.
       • {handlers} (table): The handlers used by the client as described in
         |lsp-handler|.
+      • {commands} (table): Table of command name to function which is called
+        if any LSP action (code action, code lenses, ...) triggers the
+        command. Client commands take precedence over the global command
+        registry.
       • {requests} (table): The current pending requests in flight to the
         server. Entries are key-value pairs with the key being the request ID
         while the value is a table with `type`, `bufnr`, and `method`
@@ -770,12 +774,16 @@ client()                                                      *vim.lsp.client*
         "cancel" for a cancel request. It will be "complete" ephemerally while
         executing |LspRequest| autocmds when replies are received from the
         server.
-      • {config} (table): copy of the table that was passed by the user to
-        |vim.lsp.start_client()|.
+      • {config} (table): Reference of the table that was passed by the user
+        to |vim.lsp.start_client()|.
       • {server_capabilities} (table): Response from the server sent on
         `initialize` describing the server's capabilities.
       • {progress} A ring buffer (|vim.ringbuf()|) containing progress
         messages sent by the server.
+      • {settings} Map with language server specific settings. See {config} in
+        |vim.lsp.start_client()|
+      • {flags} A table with flags for the client. See {config} in
+        |vim.lsp.start_client()|
 
 client_is_stopped({client_id})                   *vim.lsp.client_is_stopped()*
     Checks whether a client is stopped.