| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
capabilities #1889
Previously, vim.lsp.protocol.make_client_capabilities() was used if no
capabilities were specified in either the user-provided config or the
default config (base or server).
Now, the base default config table has a capabilities key with the value
of make_client_capabilities(). When creating the finalized configuration
for a server, it simply uses the finalized config which is the
user-provided config deep extended by the default config (which now
contains the default capabilities).
This means that users will no longer have to create their own customized
capabilities tables seeded from
vim.lsp.protocol.make_client_capabilities(). They simply need to create
the parts that are new or different from the defaults and pass that as
the capabilities. The rest of the defaults are filled in automatically.
For this to work properly, some tbl_extend calls were changed to
tbl_deep_extend. tbl_extend will not recursively update nested tables,
so using it wipes out any server provided defaults in nested config keys
(such as capabilities) and won't properly fill in the "rest" of the
capabilities if the user provided a smaller capabilities key in their
config.
Changing to tbl_deep_extend ensures server-specific configuration values
are preserved and that the finalized config at least contains defaults
for all client-supported capabilities.
For example, clangd's config default has:
```
local default_capabilities = {
textDocument = {
completion = {
editsNearCursor = true,
},
},
offsetEncoding = { 'utf-8', 'utf-16' },
}
```
Prior to this commit, this was the full
vim.lsp.protocol.make_client_capabilities() extended with those extra
values. However, if a user provided their _own_ capabilities to the
setup() function, tbl_extend wiped these extra values out and replaced
it with the users' capabilities, which was likely only
vim.lsp.protocol.make_client_capabilities() with some _other_ tweaks.
Now, clangd can simply provide the extras, and the setup() function will
normalize the config with all of user-provided, server-specific, and
base default capabilities.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ocamllsp: add dune as supported language
ocaml-lsp-server-1.11.3 enables 'dune' rpc integration
(you need a running `dune build --watch` command which provides the RPC
server).
This allows to reformat `dune` files, and to see `dune` and other build
errors as soon as you change a file (e.g. quite useful on newly created
files which would otherwise show an LSP error until first build).
Signed-off-by: Edwin Török <edwin@etorok.net>
* ocamllsp: dune-project and dune-workspace also mark roots
Although most dune projects will also have a *.opam file,
this file might be generated by the build system.
Newer versions of dune have a dune-project file to mark the root though,
and users can create a dune-workspace file as well.
Note that `dune` files themselves do NOT mark the root: they can be
present in subdirs too.
The rules on how `dune` itself finds the root are documented here:
https://dune.readthedocs.io/en/stable/usage.html#finding-the-root
"The root of the current workspace is determined by looking up a
dune-workspace or dune-project file in the current directory and its
parent directories. Dune requires at least one of these two files to
operate."
Signed-off-by: Edwin Török <edwin@etorok.net>
|
