feat: added stop_after_success option to formatter configuration

[c4patino]

• Added stop_after_success flag to formatter configuration.

The intention behind this flag is explained in the documentation. Essentially, we should attempt to run each of the formatters defined in the formatter list, and then break on the first one that successfully runs.

Resolves #717

[stevearc]

Currently we are able to expect that any time a formatter produces an error, it is an actual problem with the formatter. Introducing this functionality would change that assumption, and could impact the rest of our error handling. I would have to do a lot of reading and thinking to convince myself that our error handling, aggregation, and reporting all work correctly in all situations after this PR.

This seems like a pretty niche use case. Have you considered an alternate solution, such as calling conform.format and handling the fallback yourself? Perhaps something like

conform.format({ formatters = { "rustfmt_nightly" }, quiet = true }, function(err)
  if err then
    conform.format({ formatters = { "rustfmt_stable" } })
  end
end)

There's a not-well-documented feature of the format_after_save config option that you can actually return two values: the first is the opts and the second is the async callback to pass to conform.format. So you can also try something like this:

format_after_save = function(bufnr)
  if vim.b[bufnr].filetype == "rust" then
    return { quiet = true }, function(err)
      conform.format({ bufnr = bufnr, formatters = { "rustfmt_stable" } })
    end
  end
  return { }
end,

[c4patino]

Currently we are able to expect that any time a formatter produces an error, it is an actual problem with the formatter. Introducing this functionality would change that assumption, and could impact the rest of our error handling. I would have to do a lot of reading and thinking to convince myself that our error handling, aggregation, and reporting all work correctly in all situations after this PR.

Thanks for the feedback! Yeah my usecase is definitely a bit niche, though I think that there might be other cases I'm not thinking of where it would come in useful. Essentially, we are trying to add support for nix fmt. Because it is built directly into the nix binaries, the formatter will always be found, however if in a project without a flake.nix, the formatter will fail. This violates the stop_after_first behavior because the formatter is found but fails. The intention behind the stop_after_success was to allow it to continue on past the failure of nix fmt.

I think there is a hybrid of the two snippets you added which might serve the use-case? Essentially a default attempt at nix fmt, and then on failure fall back to the defined formatters.