Adapt warnings, default settings, and tests to the new lsp module. Also
change the previous warning, which I think should target the clangd
server directly, and just not `plugins.lsp`, since the clangd server is
necessary for clangd-extensions to function.
Modify warnings, tests, and default settings to work with the new lsp
module.
Update plugins/by-name/schemastore/default.nix
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Update plugins/by-name/schemastore/default.nix
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
`config` is a loaded term within modules and options.
`settings` is the name usually used for freeform config in nixvim and
most other module configurations.
A simplified replacement for `plugins.lsp`.
Eventually, once the `lsp` and `plugins.lspconfig` modules are mature,
`plugins.lsp` will be deprecated and/or aliased.
Plugins from luarocks (e.g. telescope-nvim) have dependencies specified
in propagatedBuildInputs. These dependencies are not added as plugins in
Nvim runtime. They are added to LUA_PATH env var for wrapped neovim.
This commit collects all propagatedBuildInputs from input plugin list
and puts them in the combined plugin.
Note that such dependencies are never combined, because they are not
plugins.
During the last half of the year many dependencies of plugins used in
the tests were changed in nixpkgs. To make tests more robust use a
specially crafted stub plugins.
This reverts commit bb5b0a2655.
This change defeats the purpose of the dependency test. Revert it.
The test should verify that dependencies are correctly pulled. If
upstream plugin doesn't have dependency anymore, then a suitable
alternative should be used, not dependencies added manually.
Currently we represent `vim.diagnostic.config()` as a top-level
`diagnostics` option. This means we have no clear namespace for
(e.g.) `vim.diagnostic.<action>` keymap functions.
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.