bug: "Fix clangd offset encoding" doesn't work, still "utf-8" in C/C++ buffer about lazyvim HOT 23 CLOSED

Yep, the issue can be closed but in case someone stumble over a similar issue, the problem turned out to be the kevinhwang91/nvim-ufo plugin's configuration. A section of the plug-in's config do:

...
..
      -- Tell the server the capability of foldingRange,
      -- Neovim hasn't added foldingRange to default capabilities, users must add it manually
      local capabilities = vim.lsp.protocol.make_client_capabilities()
      capabilities.textDocument.foldingRange = {
        dynamicRegistration = false,
        lineFoldingOnly = true,
      }
      local language_servers = require("lspconfig").util.available_servers() -- or list servers manually like {'gopls', 'clangd'}
...
..

Have to investigate why that cause the utf-8 to be enforced (probably being the default) but a simple fix was to add capabilities.offsetEncoding = { "utf-16" }:

      -- Tell the server the capability of foldingRange,
      -- Neovim hasn't added foldingRange to default capabilities, users must add it manually
      local capabilities = vim.lsp.protocol.make_client_capabilities()
      capabilities.textDocument.foldingRange = {
        dynamicRegistration = false,
        lineFoldingOnly = true,
      }
      capabilities.offsetEncoding = { "utf-16" }
      local language_servers = require("lspconfig").util.available_servers() -- or list servers manually like {'gopls', 'clangd'}

from lazyvim.

I believe you don't need to apply the fix if you use the LazyExtra clangd. It's already included.

from lazyvim.

@dpetka2001, that's correct and maybe I should have mentioned it. However, the core issue is that the encoding problem remains.

from lazyvim.

Yes, I'm sorry I should have specified my test was regarding clangd. But I don't use copilot, so I can't test them together. I only have the LazyExtra for clangd enabled and used the function in your first post, that you took from here and just made a keymap that's using it.

from lazyvim.

Related screencast

from lazyvim.

Please keep in mind this is a new installation with LazyVim default settings. I also tried it with my personal configuration and didn't encounter any problems. I just showed the one with LazyVim default settings, as I wanted to ensure that the default LazyVim installation encountered the problem or not.

from lazyvim.

The actual command as I typed it is :=LazyVim.opts("nvim-lspconfig").servers.clangd, but noice doesn't show it all as I typed it.

PS: = is the equivalent of doing lua vim.print. See :h :lua and :h :=

from lazyvim.

It seems that vim.lsp.protocol.make_client_capabilities returns a new object with the default capabilities of LSP servers.

I don't use nvim-ufo any more, but this is how I had it configured when I used it (see here in my dots). This way it doesn't override the LSP server capabilities, but rather extend them to also include the necessary part about foldingRange.

If you took a similar approach, I believe you wouldn't have any problems. And this way you don't mess with offsetEncoding and just leave it up to each LSP server's capabilities to use whatever it's configured to use. Because your solution changes offsetEncoding for all available LSP servers.

from lazyvim.

I may add that the only working solution I've found so far is the rather hackish solution of tweaking LspConfig's clangd.lua file directly and remove the utf-8 entry but then I run into other problems when trying to update with Lazy (or if it's Mason complaining) that discovers that the file been tampered with and display an error.

from lazyvim.

I don't use copilot but i tried with your function keybinding and it shows utf-16 to me when i open a c file.

from lazyvim.

@dpetka2001 hmm, really interesting. For clangd I presume?

The thing is that it seems like CoPilot is just causing the conflict to appear so it's not necessary for the problem. If I only open a .c file without going into insert mode, CoPilot is not yet activate. I.e. LspInfo gives:

 1 client(s) attached to this buffer: 
 
 Client: clangd (id: 1, bufnr: [7])
 	filetypes:       c, cpp, objc, objcpp, cuda, proto
 	autostart:       true
 	root directory:  test.c
 	cmd:             /home/<user>/.local/share/nvim/mason/bin/clangd
 
 Configured servers list: marksman, jsonls, yamlls, eslint, texlab, tsserver, lua_ls, clangd

and then triggering my function gives:

Buffer details:
Buffer ID: 2 | Offset Encoding: utf-8 | Client: clangd
Buffer ID: 3 | Offset Encoding: utf-8 | Client: clangd
Buffer ID: 4 | Offset Encoding: utf-8 | Client: clangd
Buffer ID: 7 | Offset Encoding: utf-8 | Client: clangd

I take it you have utf-16 given the same scenario? Very peculiar.

from lazyvim.

Thanks, I try and start over with a totally clean LazyVim config and see what happens.

from lazyvim.

Thanks, noticed the command LazyVim.opts("nvim-lspconfig").servers.clangd but that doesn't work for me. Getting an error:

E5107: Error loading lua [string ":lua"]:1: '=' expected near '<eof>'

but maybe I'm doing something wrong.

from lazyvim.

@dpetka2001 Thanks, now the command worked. But peculiar enough I get:

{
  capabilities = {
    offsetEncoding = { "utf-16" }
  },
  cmd = { "/home/<user>/.local/share/nvim/mason/bin/clangd", "--background-index", "--clang-tidy", "--header-insertion=iwyu", "--completion-style=detailed", "--function-arg-placeholders", "--fallback-style=llvm" },
  init_options = {
    clangdFileStatus = true,
    completeUnimported = true,
    usePlaceholders = true
  },
  keys = { { "<leader>cR", "<cmd>ClangdSwitchSourceHeader<cr>",
      desc = "Switch Source/Header (C/C++)",
      mode = "n"
    } },
  root_dir = <function 1>
}

i.e. offsetEncoding = { "utf-16" } 🤔.

from lazyvim.

Yes, that's what I get as well. Why is it peculiar? It's the default value in the clangd LazyExtra. This command returns the values of clangd as it is configured in nvim-lspconfig.

from lazyvim.

It's peculiar since I get utf-16 with that command but still have the conflict and utf-8 with my PrintBufferDetails command. Why isn't it consistent I wonder?

from lazyvim.

Did you try with a default LazyVim installation? Enable only clangd and copilot extras with no other changes. The PrintBufferDetails command also gave utf-16 in my test, but without copilot as I don't use it as I've already mentioned.

from lazyvim.

Will do that now and gradually move over my config to see if I can circle in what's causing this.

from lazyvim.

OK, a clean installation behave as expected with utf-16. Will rebuild now and see if I can find the culprit.

from lazyvim.

If the default LazyVim installation from your testing doesn't reproduce this problem, then we can safely assume it's not a LazyVim bug and the issue can be closed?

from lazyvim.

Maybe you would like to mention that in the plugin's repo, so corresponding documentation could be added in order to avoid this problem.

from lazyvim.

Thanks,

I write something in the UFO's repo.
And yes, I realized that it would affect all LSP-servers and that it's not optimal. I'll look at your dotfiles.

from lazyvim.

I improved on the fix for nvim-ufo a bit so that the offsetEncoding doesn't affect all servers. A bit further down in ufo's officially recommended config the language servers are looped so I simply added an if-statement for the encoding for clangd:

      local capabilities = vim.lsp.protocol.make_client_capabilities()
      capabilities.textDocument.foldingRange = {
        dynamicRegistration = false,
        lineFoldingOnly = true,
      }
      local language_servers = require("lspconfig").util.available_servers() -- or list servers manually like {'gopls', 'clangd'}
      for _, ls in ipairs(language_servers) do
        if ls == "clangd" then
          capabilities.offsetEncoding = { "utf-16" }
        end
        require("lspconfig")[ls].setup({
          capabilities = capabilities,
          -- you can add other fields for setting up lsp server in this table
        })
...
..

from lazyvim.