bug: conform.formatexpr is still returning 0 even when no formatters are present for the filetype

[ndavd]

Neovim version (nvim -v)

v0.10.0-dev-2048+g367e52cc7

Operating system/version

Linux

Add the debug logs

• I have set log_level = vim.log.levels.DEBUG and pasted the log contents below.

Log file

[DEBUG] Running formatters on /.../Foo.sol: {}
[DEBUG] No formatters found for /.../Foo.sol

Describe the bug

Being it so that no conform formatters are present its formatexpr should be returning 1 so that it may fallback to the next available formatter.

What is the severity of this bug?

breaking (some functionality is broken)

Steps To Reproduce

Open file without formatters. E.g. a Solidity file (*.sol).

Additional context

It used to work, so not sure when it exactly broke. This is the custom formatexpr that I've been using so far:

Formatexpr = function()
  local timeout_ms = 10000

  local n = require('conform').formatexpr({ timeout_ms = timeout_ms })

  if n == 0 then
    return 0
  end

  local whole_buffer_selected = vim.v.count == vim.fn.line('$')
  if whole_buffer_selected and supports_buffer_formatting() then
    -- Execute LSP buffer format (useful for those LSPs which don't support range formatting)
    vim.lsp.buf.format({ timeout_ms = timeout_ms })
    return 0
  end

  -- Fallback
  return 1
end

[wookayin]

I think this is intentional. See #238

[cryptomilk]

You might want to document the behavior and why. You should also point to gw.

[ndavd]

I see, thanks for the replies. I see there also a way to make it so that it has the same effect as before so that should fix it for me.

The issue as you can notice in my code snippet is not that I want to fallback to builtin nvim formatter, it's that if there's no conform formatter or lsp range formatting I want to check for lsp buffer formatting. What do you guys think? Could that perhaps even be added to conform itself? Some LSPs do not yet support range formatting.

[ndavd]

By the way, the example you shared is giving me an error #require("conform.lsp_format").get_format_clients() > 0 as get_format_clients takes an object, anything I should add there specifically?

[ndavd]

Looking at its code it seems that conform's formatexpr should be fallbacking to LSP buffer formatting itself, no?

[wookayin]

By the way, the example you shared is giving me an error #require("conform.lsp_format").get_format_clients() > 0 as get_format_clients takes an object, anything I should add there specifically?

Sorry it didn't work out-of-box, you can do:

-#require("conform.lsp_format").get_format_clients()
+#require("conform.lsp_format").get_format_clients({})

Looking at its code it seems that conform's formatexpr should be fallbacking to LSP buffer formatting itself, no?

Right, conform's formatexpr should fall back to LSP. In your case, there is no LSP formatter available. Note that LSP formatter also does NOT fallback to the built-in formatexpr.

[ndavd]

Right, conform's formatexpr should fall back to LSP. In your case, there is no LSP formatter available. Note that LSP formatter also does NOT fallback to the built-in formatexpr.

So that's where the issue is. I do have an LSP formatter available (solidity_ls_nomicfoundation), but it doesn't support range formatting, only buffer formatting. When that's the case I want it to run the lsp.buf.format:

local supports_buffer_formatting = function()
  return vim.iter(vim.lsp.get_clients({ bufnr = 0 })):any(function(c)
    return c.supports_method(vim.lsp.protocol.Methods.textDocument_formatting)
  end)
end

  -- Try out conform, if it doesn't work continue
  -- ...

  local whole_buffer_selected = vim.v.count == vim.fn.line('$')
  if whole_buffer_selected and supports_buffer_formatting() then
    -- Execute LSP buffer format (useful for those LSPs which don't support range formatting)
    vim.lsp.buf.format({ timeout_ms = timeout_ms })
    return 0
  end

@wookayin So my guess is that conform's formatexpr is supporting buffer formatting but it's not calling it when the motion is covering the whole buffer. If whole_buffer_selected and there's not range formatting but there is buffer formatting available (vim.lsp.protocol.Methods.textDocument_formatting) then format the buffer with LSP.

[ndavd]

If that were to become a conform feature I wouldn't even have the need for my custom formatexpr. I think it makes sense, no?

[wookayin]

I don't think I clearly get what you exactly want to achieve here. Are you saying that the behavior fixed in #255 (i.e. does not fallback to the built-in formatexpr) doesn't make sense, or now are we talking about your specific use-case questions where you'd want to fallback to "LSP formatter" or "built-in formatter" when range-formatting is requested but the range is the entire buffer? In your code, you should not use the return value of require('conform').formatexpr (it returned 0) but decide whether you'd want to fall back or not to LSP or whatever formatters.

[ndavd]

@wookayin I guess I started talking about making my custom formatexpr work but then realized that conform's formatexpr is doing just almost the same as I'm trying to achieve.

So consider the example of an LSP that supports buffer format, that means vim.lsp.protocol.Methods.textDocument_formatting. Conform's formatexpr only uses LSPs formatting for ranges vim.lsp.protocol.Methods.textDocument_rangeFormatting.

So I propose that, when the formatexpr is being used to format the whole file (vim.v.count == vim.fn.line('$')) use the buffer formatting and not the range formatting. Because some LSPs might not support range formatting, while supporting buffer formatting.

[wookayin]

That sounds like a fair and good idea, but I feel that would be slightly off topic from this issue (which is on the fallback behavior of "formatexpr"). But please feel free to open a new feature request.

[ndavd]

Ah yes totally. I realized what conform was doing after you shared the PR. Will open another one for a feature request.