This new `plugins.lsp.servers.vue_ls.tslsIntegration` is a shameless
copy of of pre-existing `plugins.lsp.servers.volar.tslsIntegration`
option.
Full disclosure: I have not tested this as I use the newer `lsp` module.
I'm not sure if this fixes
https://github.com/nix-community/nixvim/issues/3600, but it's a least
part of it.
26 new LSPs were added when we updated the update script in
b9c5a75cc6
Add a package association for all the new LSPs I was able to find a
package for.
This is nearly a full rewrite of the lspconfig-servers update-script,
migrating it to the new `lsp/` directory system and simplifying where
possible.
- plugins/lsp: adapt to new file format
- flake/locate-lsp-packages: update for new lspconfig file format
- generated: Updated lspconfig-servers.json
A new update script will check which "old" files do not have an
equivalent "new" file, then the plugins.lsp module will create a
removal assertion for any servers that are listed in the generated
file.
- Re-implement setup wrapping and capabilities to preserve existing
behaviour
- Alias `package` options to new lsp module
- Alias `packageFallback` options to new lsp module
- Alias `preConfig` and `postConfig` to `lsp.luaConfig`
Previously I said we alias the definitions instead of the value to allow
`mkOrder` to work correctly. That is incorrect, as order-priorities are
already sorted in `<opt>.definitions`.
The actual reason to use the definitions instead of the final value is
to avoid inf-recursion. The "from" option's `apply` function would read
the "to" option's value, which is defined based on the "from" option's
value, which is set by the "from" option's apply function...
For a one-way binding, `mkDerivedConfig` is best. For a two-way binding,
`mkAliasAndWrapDefsWithPriority` is necessary.
This simplifies the impl by doing global on-attach logic in a
`LspAttach` autocmd instead of adding lua lines to each server's
individual `on_attach` callback.
This is effectively a `mkAliasOptionModule` alias, other than the alias
only being applied when `plugins.lsp.enable`.
nvim-lspconfig historically used `root_dir`, along with util functions
like `root_pattern`.
Now that neovim's own LSP API is used, `root_dir` appears to be subtly
different and `root_markers` is introduced to replace `util.root_pattern`.
Since we cannot easily warn about the `root_dir` differences, it can
usually be replaced with `root_markers`, and can still be manually
configured via `extraOptions` if needed; the simplest approach here is
to remove the `rootDir` option.