lsp_as_default_formatter not work

[BBboy01]

Neovim version (nvim -v)

v0.11.5

Operating system/version

macOS Tahoe 26.1

Expected behaviour

Apply lsp formatter result

Actual behaviour

do nothing

Output of :checkhealth guard

==============================================================================
guard:                                                                    1 ⚠️

Executable check ~
- ✅ OK npx found
- ✅ OK stylua found
- ✅ OK gofumpt found
- ✅ OK shfmt found
- ✅ OK shellcheck found
- ✅ OK rustfmt found
- ✅ OK fish_indent found
- ⚠️ WARNING It seems that mason.nvim is installed,in which case checkhealth may be inaccurate. Please add your mason bin path to PATH to avoid potential issues.

Settings ~
- ✅ OK fmt_on_save: false
- ✅ OK lsp_as_default_formatter: true
- ✅ OK save_on_fmt: false

Tools registered for current buffer (bufnr 2) ~
- ✅ OK Current buffer has filetype toml:
- 1 formatter autocmds attached
- 0 linter autocmds attached
- formatters:
- {
    fn = <function 1>
  }

How to reproduce the issue

open a toml file

add taplo as lsp

:lua Guard fmt

I noticed the formatted code already generated but not applied success

guard.nvim/lua/guard/lsp.lua

Lines 23 to 37 in f0080b7

	vim.lsp.util.apply_text_edits = function(text_edits, _, offset_encoding)
	-- the target buffer must be buf, we apply it to our scratch buffer
	n_edits = n_edits - 1
	vim.tbl_map(function(edit)
	edit.range.start.line = edit.range.start.line - line_offset
	edit.range['end'].line = edit.range['end'].line - line_offset
	end, text_edits)
	apply(text_edits, scratch, offset_encoding)
	if n_edits == 0 then
	vim.lsp.util.apply_text_edits = apply
	local lines = api.nvim_buf_get_lines(scratch, 0, -1, false)
	api.nvim_command('silent! bwipe! ' .. scratch)
	coroutine.resume(co, table.concat(lines, '\n'))
	end
	end

After commenting out this code, formatter apply success

Are you sure this is a min repro?

• I understand that if my repro step is too complicated (e.g. here is my 1k+ line config and please help me), developers might not be able to help.
• I can confirm that my reproduction step only involves vim.opt.rtp and configuration themselves

[xiaoshihou514]

@glepnir Maybe lsp module is not migrated to async? We should add a test for that.

[alexkornitzer]

This has been slowly annoying more and more but I have finally had time to dig into what is going on. The current implementation as identified will not work correctly as the M.format function is expected to return a string. Furthermore the lsp.format function is trying to drive the coroutine but this is being handled by the async code in _async, thus when it yields it actually causes an error to be thrown and the coroutine dies.

So one potential approach is to make a new coroutine and wait on that, which looks something like so:

diff --git a/lua/guard/lsp.lua b/lua/guard/lsp.lua
index 1c0a112..67f2d17 100644
--- a/lua/guard/lsp.lua
+++ b/lua/guard/lsp.lua
@@ -7,12 +7,17 @@ local apply = vim.lsp.util.apply_text_edits
 ---@param acc string
 ---@return string
 function M.format(buf, range, acc)
-  local co = assert(coroutine.running())
+  assert(coroutine.running())
   local clients = vim.lsp.get_clients({ bufnr = buf, method = 'textDocument/formatting' })
   if #clients == 0 then
     return acc
   end

+  local res
+  local co = coroutine.create(function()
+    return coroutine.yield()
+  end)
+
   -- use a temporary buffer to apply edits
   local scratch = api.nvim_create_buf(false, true)
   local n_edits = #clients
@@ -29,10 +34,7 @@ function M.format(buf, range, acc)
     end, text_edits)
     apply(text_edits, scratch, offset_encoding)
     if n_edits == 0 then
-      vim.lsp.util.apply_text_edits = apply
-      local lines = api.nvim_buf_get_lines(scratch, 0, -1, false)
-      api.nvim_command('silent! bwipe! ' .. scratch)
-      coroutine.resume(co, table.concat(lines, '\n'))
+      res = coroutine.resume(co)
     end
   end

@@ -42,7 +44,14 @@ function M.format(buf, range, acc)
     async = true,
   })

-  return (coroutine.yield())
+  vim.wait(1000, function()
+    return res ~= nil
+  end)
+
+  vim.lsp.util.apply_text_edits = apply
+  local lines = api.nvim_buf_get_lines(scratch, 0, -1, false)
+  api.nvim_command('silent! bwipe! ' .. scratch)
+  return table.concat(lines, '\n')
 end

 return M

But this only allows vim.lsp.buf.format to be run in async mode and probably is going to be no faster than how it runs in blocking mode (guessing here), but this does appear to align with how other formatters are run within Guard. If you are happy with the above just let me know and I can raise a PR for it.

[xiaoshihou514]

@alexkornitzer The vim.wait(1000) looks pretty hacky, but thanks for investigating! Let me try to resolve it this afternoon.

[xiaoshihou514]

@alexkornitzer @BBboy01 Should be working now I think.

[alexkornitzer]

@xiaoshihou514 thanks for looking into that. So that looks to be working for the single client (with changes) use case but it is not working for when there are clients that report no changes (which is a big problem when multiple clients are registered) as it appears that if a client has formatting support but no formatting to apply it won't call the apply edits and therefore won't decrement the counter, and thus the callback will not be triggered. This is why in the above I had the cleanup code run after the wait.

[alexkornitzer]

With the latest build 2.6.2 on multi client (Python in this case) I don't get any formatting as its picking the first client only, and the second client is the one I actually need, pylsp is registering as 1, and ruff is registering as 2. In old Guard (I think 1.x) this could be fixed by doing:

ft("python"):fmt({
  fn = function(buf, range)
    vim.lsp.buf.format({
    buffer = buf,
    range = range,
    async = true,
    name = "ruff",
  })
  end
})

But in v2 this only now half works, it will run on Guard fmt but it won't run on save. So I guess save is still using the new single client only fix that will select client 1 (or more accurately the first client that reports formatting capability)?

[xiaoshihou514]

@alexkornitzer

• Only the auto-registered lsp formatter use the first lsp (it used to be half broken for the multiple lsp case anyway). Anything else should stay the same. Format on save should work since it's roughly just "au BufWritePre Guard fmt", please open a new issue if that's not the case (oh no)
• I think in 1.x lsp format is handled by simply vim.lsp.buf.format, however, it does not compose well with other formatters (one of the initiatives for 2.x is for the plugin to be generic enough to support any formatting/linting logic).
• From what you described, pylsp and ruff both claim to support formatting (or else they would be skipped), but you don't like pylsp's formatting? I think there are multiple solutions to this:
  • If you just want ruff, ruff is in guard collection via ft("python"):fmt("ruff")
  • If you want to skip pylsp, I think pylsp is a frontend that aggregates a bunch of tools, maybe there's a way to specify that you don't want formatting? (I might be very wrong here)
• Basically, lsp_as_default_formatter will stay simple and only use the first lsp (I couldn't think of a nice trick to handle the no text edit case, @glepnir any thoughts?)

I hope this solves your problem.

[alexkornitzer]

@xiaoshihou514 that all makes sense, thanks again for spending the time to get the core issue fixed. My mistake on the format on save as that is working, not sure what was going on there when I initially tested it, but it does have an issue with it not setting the buffer correctly so i'll create an issue for that.