warning: multiple different client_offset encodings

[kevinpowell]

liking the direction this plugin is going. I was quite happy to see mason integration, and the lsp approach is superior.

However, I get the "multiple different client_offset encodings" warning -- seems to be something to do with my other lsp servers (most likely clangd). Anyone else having this trouble?

[McPatate]

Thank you for the kind words @kevinpowell.

Is the warning emitted by llm.nvim?

[McPatate]

I have a ton of LSP servers on my setup and I've never, afaicr, encountered this issue.

How did you deduce clangd might have something to do with it? I personally don't have it, so that might make sense.

And yes, not the best UX having a warning on every keystroke 😅

[kevinpowell]

If I edit a file that clangd does not attach to, but llm.nvim does (a javascript file for example) -- then I don't get this warning. However a C/C++ file has both lsp servers attached, and does generate the warning.

Also, a few quick searches with Google indicate that other people who have encountered this error with other lsp servers have been using clangd in addition to some other server e.g. null-ls

[kevinpowell]

Had a bit of time to mess around with nvim an llm-ls today. It turns out that this issue is definitely caused by the way my nvim setup uses clangd.
Specifically, the nvim-lspconfig plugin that I use allows the clangd lsp client to use utf-8 offset encoding. This, apparently, is preferred by clangd. However, the lua code in llm.nvim uses the default settings for the llm-ls client, and one of those defaults is utf-16 offset encoding. When I edit a cpp file, both clangd and llm-lsp attach to the buffer, and voila -- the warning appears (on every keystroke)

I was able to avoid the warning by overriding the clangd client's capabilities.offset_encoding to be { 'utf-16' } -- this didn't affect clangd at all, and it made llm.nvim and clangd coexist peacefully.

[McPatate]

Great find @kevinpowell!

[IamTheFij]

Ironically, I'm getting seeing the opposite of this now.

vim.lsp: Active Clients ~
- llm-ls (id: 1)
  - Version: 0.5.2
  - Settings: {}
  - Attached buffers: 1, 9
- pyright (id: 2)
  - Version: ? (no serverInfo.version response)
  - Command: { "pyright-langserver", "--stdio" }
  - Settings: {
      python = {
        analysis = {
          autoSearchPaths = true,
          diagnosticMode = "openFilesOnly",
          useLibraryCodeForTypes = true
        }
      }
    }
  - Attached buffers: 1
- null-ls (id: 3)
  - Version: ? (no serverInfo.version response)
  - Settings: {}
  - Attached buffers: 1

vim.lsp: Position Encodings ~
- ⚠️ WARNING Found buffers attached to multiple clients with different position encodings.
  - Buffer 1: UTF-16 (client id(s): 2, 3), UTF-8 (client id(s): 1)
  - ADVICE:
    - Use the positionEncodings client capability to ensure all clients use the same position encoding

This suggests that llm-ls is configured to use UTF-8 rather than UTF-16.

This patch should be in the latest version of llm-ls (0.5.3) which seems to be what I've downloaded based on file name, despite --version saying 0.5.2.