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?

[kevinpowell]

llm.nvim functions despite the warning. However, the warning is re-issued at every keystroke. I'd have to add special configuration to ignore the warning if I wanted to continue using 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!