warning: multiple different client offset_encodings detected for buffer, this is not supported yet

[kylo252]

MAINTAINER EDIT: this is not a null-ls issue, and you will see the same warning when two clients with different offset encodings are attached to the same buffer. As the error message states, this is not supported yet, and the fundamental fix must be implemented upstream.

This is a legitimate warning, but if you don't care and just want to suppress it, you can filter it out by overriding vim.notify:

local notify = vim.notify
vim.notify = function(msg, ...)
    if msg:match("warning: multiple different client offset_encodings") then
        return
    end

    notify(msg, ...)
end

Any further issues about this topic will be closed.

---

FAQ

• I have checked the FAQ and it didn't resolve my problem.

Issues

• I have checked existing issues and there are no issues with the same problem.

Neovim Version

NVIM v0.7.0-dev+717-gf37c5f180

null-ls config

require("null-ls").setup({
    sources = {
        require("null-ls").builtins.code_actions.gitsigns,
    },
})

Steps to reproduce

This validation is introduced in neovim/neovim#16382

You need to have clangd which sets an offset encoding by default, running and then any source that attaches to the same buffer.

Expected behavior

NA

Actual behavior

NA

Debug log

NA

Help

Yes, but I don't know how to start. I would need guidance

Implementation help

Not really sure how we can get around this. I thought It's probably sufficient to set the same encoding value as clangd but that didn't seem to fix it.

diff --git a/lua/null-ls/rpc.lua b/lua/null-ls/rpc.lua
index 9e45c0a..e9efa6d 100644
--- a/lua/null-ls/rpc.lua
+++ b/lua/null-ls/rpc.lua
@@ -44,6 +44,7 @@ local capabilities = {
         openClose = true,
         save = true,
     },
+    offsetEncoding = { "utf-8", "utf-16" },
 }
 
 M.capabilities = capabilities

I also have no idea if there are any downsides to that.

[jose-elias-alvarez]

So we can set client.offset_encoding by passing it into the vim.lsp.start_client options:

diff --git a/lua/null-ls/client.lua b/lua/null-ls/client.lua
index a49aebc..24ada84 100644
--- a/lua/null-ls/client.lua
+++ b/lua/null-ls/client.lua
@@ -69,6 +69,7 @@ M.start_client = function(fname)
                 )
             end
         end),
+        offset_encoding = "utf-8",
     }

     log:trace("starting null-ls client")

This fixes the warning when using clangd but creates the same issues for servers using utf-16. Changing this also immediately breaks formatting and probably has other side effects. I'm actually not sure how clangd handles setting offsetEncoding via capabilities – this docstring hints that it's doing something special in on_init, but I don't know where.

If I understand correctly, this is a legitimate warning that would also be triggered when using 2 actual LSP servers with different offset encodings, right? I'm not sure if there's anything we can do about this until multiple offset encodings are supported (apart from maybe putting in an upstream PR to reduce the frequency of the warning, since it's pretty aggressive).

[mjlbach]

FYI we didn't use to support mixed offsetEncodings, it used to send the wrong ranges (always utf-16). We changed it to send the correct ranges but with the limitation that it only supports a single offset encoding per buffer. All clients attached to a given buffer must have the same client.offset_encoding (capability only indicates to the language server what our client supports). I assume the issue for null-ls is that there cannot be "groups" of null-ls clients with different offset encodings.

[kylo252]

I was doing some testing and here are the results.

Changing the settings in https://github.com/neovim/nvim-lspconfig/blob/c37bf4a2e87df0da5895402b01b427442e0633ff/lua/lspconfig/server_configurations/clangd.lua

-- results in 'utf-8'
offsetEncoding = { 'utf-8', 'utf-16' },

 -- results in 'utf-16', probably wrong syntax
offsetEncoding = 'utf-8',

-- results in 'utf-8' but null-ls is 'utf-16' anyway
offsetEncoding = { 'utf-8' },

Doing the same change for null-ls doesn't do anything, still not sure why.

---

Edit: I was probably modifying the wrong value in null-ls 😅

[jose-elias-alvarez]

FYI we didn't use to support mixed offsetEncodings, it used to send the wrong ranges (always utf-16). We changed it to send the correct ranges but with the limitation that it only supports a single offset encoding per buffer. All clients attached to a given buffer must have the same client.offset_encoding (capability only indicates to the language server what our client supports). I assume the issue for null-ls is that there cannot be "groups" of null-ls clients with different offset encodings.

Thanks for the info, this makes sense. The warning should only pop up in the presence of a different client, since all null-ls clients (and there should only be one unless something went wrong) will always have the same offset encoding.

@kylo252 I think this diff makes utf-8 work (tests are passing, at least, and I don't immediately see any bad behavior):

diff --git a/lua/null-ls/client.lua b/lua/null-ls/client.lua
index a49aebc..97c0a3d 100644
--- a/lua/null-ls/client.lua
+++ b/lua/null-ls/client.lua
@@ -69,6 +69,7 @@ M.start_client = function(fname)
                 )
             end
         end),
+        client_encoding = "utf-8",
     }

     log:trace("starting null-ls client")
diff --git a/lua/null-ls/diff.lua b/lua/null-ls/diff.lua
index 20e3dab..311524f 100644
--- a/lua/null-ls/diff.lua
+++ b/lua/null-ls/diff.lua
@@ -140,8 +140,8 @@ function M.compute_diff(old_lines, new_lines, line_ending)
         adj_end_char = #old_lines[#old_lines + end_line + 1] + end_char + 1
     end

-    _, start_char = vim.str_utfindex(old_lines[start_line], start_char - 1)
-    _, end_char = vim.str_utfindex(old_lines[#old_lines + end_line + 1], adj_end_char)
+    start_char = start_char - 1
+    end_char = adj_end_char

     local result = {
         range = {

The issue is then that we get the same warning with utf-16 clients. Given that mixing client offset encodings is a legitimate issue, I don't really know if there's a good solution until that situation is handled upstream (which at a glance seems like a real challenge).

[levouh]

For visibility from a discussion here, an interim "solution" (at least to get rid of the warning that happens on every key press in insert mode) is to do what is mentioned there:

local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities.offsetEncoding = { "utf-16" }
require("lspconfig").clangd.setup({ capabilities = capabilities })

and all seems to still work as normal. I run clangd + use clang-format from null-ls and have not had any issues. This "works" because the default assumed encoding (as null-ls provides none) is utf-16.

[kylo252]

I run clangd + use clang-format from null-ls and have not had any issues.

Just a heads-up, clangd can already use clang-format natively, so there's no need to invoke null-ls.

[jose-elias-alvarez]

For visibility from a discussion here, an interim "solution" (at least to get rid of the warning that happens on every key press in insert mode) is to do what is mentioned there:

local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities.offsetEncoding = { "utf-16" }
require("lspconfig").clangd.setup({ capabilities = capabilities })

and all seems to still work as normal. I run clangd + use clang-format from null-ls and have not had any issues. This "works" because the default assumed encoding (as null-ls provides none) is utf-16.

Thanks for the workaround! I'll pin the issue for now.

[Chaitanyabsprip]

I haven't even mentioned c filetype in null-ls config, still it attaches to the buffer for some reason.

[jose-elias-alvarez]

@Chaitanyabsprip From your dotfiles, it looks like you are using the gitsigns built-in, which is active for all filetypes by default. You can configure filetypes for that built-in or use one of the workarounds mentioned here.

Ideally, null-ls wouldn't receive textDocument/didChange notifications at all without a diagnostics source registered, which would avoid your issue, but it's not possible with the current architecture. Eventually I want null-ls to independently register itself for change events, but that'll take time and work.

[pgherveou]

👋 there, I am also running into this
I am using the ccls lsp client and clang_format through null-ls for formatting
I used capabilities.offsetEncoding = { "utf-16" } when configuring ccls, but I am seeing the warning.

Is there an easy way to debug this?

edit: nvm this works if I switch to clang instead of ccls

[sanfusu]

Just some relevant information

https://github.com/neovim/neovim/blob/b455e0179b4288c69e6231bfcf8d1c132b78f2fc/runtime/lua/vim/lsp/util.lua#L1812

[ybisland]

Even though I used capabilities.offsetEncoding = { "utf-16" }, I also see this warning when using clangd lsp and cppcheck through null-ls for diagnostics.

Neovim Version:
NVIM v0.7.0
Build type: Release

null-ls config:

require("null-ls").setup({
    sources = {
        require("null-ls").builtins.diagnostics.cppcheck,
    },
})

[kylo252]

Even though I used capabilities.offsetEncoding = { "utf-16" }, I also see this warning when using clangd lsp and cppcheck through null-ls for diagnostics.

are you adding the setting to clangd or null-ls? since it's a command-line flag, it should show up as part of the clangd command in :LspInfo

[shunlir]

Is it possible to make null-ls's offsetEncoding configurable? ccls only supports utf-32, this means the two lsp clients have different offset_encoding, and have the warning.
https://github.com/MaskRay/ccls/blob/master/src/messages/initialize.cc#L229

[jose-elias-alvarez]

Is it possible to make null-ls's offsetEncoding configurable? ccls only supports utf-32, this means the two lsp clients have different offset_encoding, and have the warning. https://github.com/MaskRay/ccls/blob/master/src/messages/initialize.cc#L229

It is configurable for null-ls in the same way it's configurable for any other client.

I'm going to update the OP with a workaround and close this issue, since it is not specific to null-ls (you can easily replicate it by attaching 2 LSP clients with different offset encoding to a single buffer).

[shunlir]

I found a simple way to config null-ls to use any offsetEncoding.
(It works together with clangd which is configured utf-32, to align with ccls which only supports utf-32)

  require("null-ls").setup({
    on_init = function(new_client, _) 
      new_client.offset_encoding = 'utf-32'
    end,
  })

Given null-ls has some shortcuts for its client/server interaction, it's not required to do the offsetEncoding negotiation, for which the details, see help vim.lsp.start_client on_init about how offsetEncoding/offset_encoding should work.