Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about default_capabilities #44

Closed
weeman1337 opened this issue Oct 20, 2022 · 7 comments 路 Fixed by #64
Closed

Question about default_capabilities #44

weeman1337 opened this issue Oct 20, 2022 · 7 comments 路 Fixed by #64

Comments

@weeman1337
Copy link

Hello 馃憢 Just upgraded my setup and found the change about client capabilities.

All examples look like this:

-- The nvim-cmp almost supports LSP's capabilities so You should advertise it to LSP servers..
local capabilities = require('cmp_nvim_lsp').default_capabilities()

-- The following example advertise capabilities to `clangd`.
require'lspconfig'.clangd.setup {
  capabilities = capabilities,
}

Doesn't that mean that I not consider all other capabilities, that nvim has?

Maybe something like this would be better:

local capabilities = vim.lsp.protocol.make_client_capabilities()
local cmp_capabilities = require("cmp_nvim_lsp").default_capabilities()
capabilities.textDocument.completion = cmp_capabilities.textDocument.completion
@skwee357
Copy link

Following. I'm also not sure how to migrate properly, because before the breaking change, I was using

    local capabilities = vim.lsp.protocol.make_client_capabilities()
    capabilities = require('cmp_nvim_lsp').update_capabilities(capabilities)

@efueyo
Copy link

efueyo commented Oct 28, 2022

Following. I'm also not sure how to migrate properly, because before the breaking change, I was using

    local capabilities = vim.lsp.protocol.make_client_capabilities()
    capabilities = require('cmp_nvim_lsp').update_capabilities(capabilities)

I just followed what was commented on #38 (comment)
and it seemed to work for me @skwee357
just replace the two lines by local capabilities = require("cmp_nvim_lsp").default_capabilities()

@dimbleby
Copy link

#42 (comment) looks like better advice.

The suggestion at the previous comment - and currently in the README - goes wrong exactly as this issue reports: it throws away all the capabilities declared by the the core neovim client.

@mgnsk
Copy link

mgnsk commented Jun 14, 2023

#42 (comment) looks like better advice.

The suggestion at the previous comment - and currently in the README - goes wrong exactly as this issue reports: it throws away all the capabilities declared by the the core neovim client.

After some research I can confirm that this works at the moment. Extending the default capabilities with the specified new capabilities.

            local lsp = require("lspconfig")
            lsp.util.default_config = vim.tbl_deep_extend("force", lsp.util.default_config, {
                capabilities = require("cmp_nvim_lsp").default_capabilities(),
            })

But hrsh7th/nvim-cmp#1265 is open, I think it also needs documentation in README as well.

wookayin added a commit to wookayin/cmp-nvim-lsp that referenced this issue Nov 16, 2023
Using `require('cmp_nvim_lsp').default_capabilities()` alone will be not
enough. We have to merge with the default LSP capabilities producced by
`vim.lsp.protocol.make_client_capabilities()`.

See hrsh7th#42 and hrsh7th#44.
@liskin
Copy link

liskin commented Dec 10, 2023

I don't think this is a problem. nvim-lspconfig internally performs tbl_deep_extend to merge nvim's capabilities with defaults for a given language server and then again to merge that with the user configuration (cmp_nvim_lsp's default_capabilities). The examples work correctly indeed, and I've verified by doing print(vim.inspect(config.capabilities)) in on_setup that the resulting capabilities structure has everything it should have.

hrsh7th pushed a commit that referenced this issue Dec 10, 2023
Using `require('cmp_nvim_lsp').default_capabilities()` alone will be not
enough. We have to merge with the default LSP capabilities producced by
`vim.lsp.protocol.make_client_capabilities()`.

See #42 and #44.
@charypar
Copy link

charypar commented May 6, 2024

This seems like the closes issue to the root cause of a problem I've spent a day and night chasing down.

The symptom was rust-analyzer hanging for a long time at the startup in a large directory, saying "Roots Scanned". At the same time fseventsd on macOS was using close to a 100% of a CPU core, while rust-analyzer was hovering around 18%.

Not sure of the specific interaction of plugins, but using require("cmp_nvim_lsp").default_capabilities() with mason lspconfig seems to override nvim lsp's defaults.

In my case, the key setting was workspace.didChangeWatchedFiles.dynamicRegistration which needs to be set to true for rust-analyzer to work reasonably fast in large directories (my hypothesis is that when set to false, rust analyzer attempts to set up a watch with the OS on every file in the workspace).

As far as I can tell, the default is true, but when setting up the LSP like so:

        local lspconfig = require("lspconfig")
        local mason_lspconfig = require("mason-lspconfig")
        local cmp_nvim_lsp = require("cmp_nvim_lsp")

        local capabilities = cmp_nvim_lsp.default_capabilities()

        mason_lspconfig.setup_handlers({
            function(server_name)
                lspconfig[server_name].setup({
                    capabilities = capabilities,
                })
            end,
        })

it ends up being set to false - rust-analyzer behaves differently (and correctly) if I add this line:

        local capabilities = cmp_nvim_lsp.default_capabilities()
        capabilities.workspace = { didChangeWatchedFiles = { dynamicRegistration = true } } -- <- addded line

Not sure if mason-lspconfig can influence this, as I read the code, it simply calls the handler, which talks to lspconfig directly.

This is as far as I got, being new to neovim, I'm not sure how to trace and debug the configuration values for definitive proof, but hopefully it helps.

@charypar
Copy link

charypar commented May 6, 2024

Ah, upon further investigation, default for dynamicRegistration is only true on nightly, 0.9.5 still defaults to false. That explains things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants