Issue with clangd and nvim-lspconfig on_attach

[arntanguy]

Hi,

I must be missing something, but I am new to this project and still a bit confused how it exactly works, so please bear with me.

I tried adding clangd lsp from clang-tools to my configuration.

Doing:

  config.specs.cpp = {
    enable = true;
    data = null;
    extraPackages = with pkgs; [
      clang-tools
    ];
  };

And in my init.lua, I tried doing like the other already defined LSPs:

  {
    "clangd",
    for_cat = "cpp",

    lsp = {
      filetypes = { "c", "cpp" },
    },
  },

This kind-of works, clangd LSP is indeed active. However I do not get any of the keybinds defined in nvim-lspconfig's before function

    before = function(_)
      vim.lsp.config('*', {
        on_attach = function(_, bufnr) ...
      })
    end,

However if I add my own before function to clangd, this works:

  {
    "clangd",
    for_cat = "cpp",
    before = function(_)
      vim.lsp.config('clangd', {
        on_attach = my_lsp_on_attach,
      })
    end,

    lsp = {
      filetypes = { "c", "cpp" },
      settings = {
      clangd = {
        shit = ""
      },
      },
    },
  },

Am I missing something here or is this the expected behaviour?

[BirdeeHub]

This is honestly probably more of an issue for lze or lzextras?

If it is an issue, nix has done its part by that point you described, so it is not an issue with this repo in particular, other than maybe for the neovim starter template.

However I do also maintain both those plugins, so lets work through it.

Can you verify that the before hook of the nvim-lspconfig spec is running at all? Put a print("HELLO FROM NVIM_LSPCONFIG BEFORE") in it, go into a file of a filetype for which you have an lsp, and if it doesnt pop up type :messages

If it isnt there, then it isn't running at all and that is a bug in lze or lzextras which I will look into and fix (It should run before the first lsp hook triggered)

If it is running, something else is setting vim.lsp.config("*", { on_attach = ???, }) between when the lspconfig spec is being called, and clangd, thus overriding the setting.

You can check, run print(vim.inspect(vim.lsp.config._configs["*"])) from the before hook in your clangd spec to see what it is at that point, or in the lsp hook in the nvim-lspconfig spec when the filetype is cpp or something to see what it is right before it gets the stuff from the lsp field of the clangd spec.

[BirdeeHub]

Ok. So actually, I appear to also be experiencing this issue.

However.

I also have verified that it is all working as I expect

What is even weirder, is that for other lsps, it does indeed appear to be working.

But yes, for clangd I also seem to be experiencing this??

  {
    "nvim-lspconfig",
    auto_enable = true,
    priority = 50,
    lsp = function(plugin)
      if plugin.name == "clangd" then
        vim.lsp.config._configs["*"].on_attach() -- This is calling MY function, which I set in the before hook below.
        -- So, whatever is going on, it is getting all the way through all my code correctly
        -- and the values are as I would expect them to be right here before
        -- calling vim.lsp.enable with the settings from the clangd spec
      end
      vim.lsp.config(plugin.name, plugin.lsp or {})
      vim.lsp.enable(plugin.name)
    end,
    before = function(_)
      vim.lsp.config('*', {
        on_attach = require(MP:relpath 'on_attach'),
      })
    end,
  },

[BirdeeHub]

https://github.com/neovim/nvim-lspconfig/blob/ead0f5f342d8d323441e7d4b88f0fc436a81ad5f/lsp/clangd.lua#L95

ahahaha that is why

nvim-lspconfig sets on_attach for clangd themselves.

This overrides things provided by "*"

To work around this slightly cleaner than you were doing, instead of

  {
    "clangd",
    for_cat = "cpp",
    before = function(_)
      vim.lsp.config('clangd', {
        on_attach = my_lsp_on_attach,
      })
    end,

    lsp = {
      filetypes = { "c", "cpp" },
      settings = {
        clangd = {
          shit = ""
        },
      },
    },
  },

do

  {
    "clangd",
    for_cat = "cpp",
    lsp = {
      filetypes = { "c", "cpp" },
      on_attach = my_lsp_on_attach,
      settings = {
        clangd = {
          shit = ""
        },
      },
    },
  },

You could also do something like this instead, which would do that for all of them, basically

  {
    "nvim-lspconfig",
    auto_enable = true,
    priority = 50,
    lsp = function(plugin)
      vim.lsp.config(plugin.name, plugin.lsp or {})
      vim.lsp.config(plugin.name, { on_attach = (plugin.lsp or {}).on_attach or my_lsp_on_attach })
      vim.lsp.enable(plugin.name)
    end,
    -- before = function(_)
    --   vim.lsp.config('*', {
    --     on_attach = my_lsp_on_attach,
    --   })
    -- end,
  },

Even better, you should add the things that they were doing in their hook they set to your on_attach

  {
    "clangd",
    for_cat = "cpp",
    lsp = {
      filetypes = { "c", "cpp" },
      on_attach = function(client, bufnr)
        -- call your on_attach
        my_lsp_on_attach(client, bufnr)
        -- the stuff they were adding (getting path to plugin from info plugin somehow)
        dofile(require(vim.g.nix_info_plugin_name).plugins.<lazy or start idk>['nvim-lspconfig'] .. "/lsp/clangd.lua").on_attach(client, bufnr)
      end,
      settings = {
        clangd = {
          shit = ""
        },
      },
    },
  },

[BirdeeHub]

I just found out that I typo'd /lsp/clangd.nix instead of /lsp/clangd.lua in my last version of my suggested fix when I was putting it here lol but otherwise, its fine XD

[BirdeeHub]

Ok, so, given that the issue is nvim-lspconfig's definition for clangd, I suggest taking it up with them?

Luckily, you can work around it in any of the above ways.

Im not sure what I can do about this here.

I'm not entirely sure what they are supposed to do about it either, I don't know if they have a way to set that stuff without overwriting the hook, but luckily that is not my task here XD

One could run into this using vanilla nvim + nvim-lspconfig + clangd with 0 other plugins or nix involved.

[arntanguy]

Wow thanks for the time investigating the issue in such through manner! Indeed, it seems that there is not much you can do here, and the workarounds should be good-enough for me, at least now I understand what's going on. I'll give it a try as soon as possible, and report back here if that indeed does the trick for me 👍

[BirdeeHub]

Once you pointed it out, I had to fix it in my own config 🤣