* fix: util.root_pattern prioritises pattern order
Instead of traversing the filesystem upwards once and
returning the first match of all the patterns, it traverses
the filesystem upwards once for each pattern. This means
that the order of the patterns provided matters, and the
highest priority patterns should be put first. Also updated
corresponding tests.
* docs: update util.root_pattern description
* feat: rename sumneko_lua -> lua_language_server
* refactor(sumneko_lua): use vim.deprecate
* refactor: handle deprecated server aliases in one place
* refactor: put server aliases in a function
* feat: rename lua_language_server -> lua_ls
This is to allow 3rd party plugins to discern between what is
lspconfig's vendored server config and what the user provided.
Currently, these are merged into a single table which is passed to the
on_setup hook. Passing user_config as a 2nd argument would allow 3rd
party plugins to apply a more sensible precedence of configs.
* switch to lua api for autocommands
* switch to nvim_create_user_command
* move to lua plugin initialization
NOTICE: Defining commands in server configurations will be deprecated in
future releases.
See `:help lspconfig.txt` to setup the same in an `on_attach` function.
Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com>
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.
1. setting `runtimepath` to `$VIMRUNTIME` _only_ (skipping user plugins but
still sourcing builtin filetype plugins)
2. putting the `packer_compiled.lua` into a temp directory to avoid clobbering
the user's own (or, worse, conflicting if they configured a non-standard
location themselves)
3. updating installed plugins unconditionally (to prevent stale plugins from
earlier tests)
