FR: Integrate organizeImport, fixAll into formatting

[chrisgrieser]

Right now, ruff format / textDocument/formatting apply formatting, while organizeImports and fixAll are available independently, e.g. as code actions.

I think it would make sense to have the option to run all three (organizeImports, fixAll, formatting) with one command by integrating the former two into the formatting capabilities. Combining import-sorting and formatting is not uncommon, a few formatters like for example stylua already do that.

Currently, doing that in ruff requires a bunch of workarounds (see e.g., #119 or #95), which have some minor hiccups as LSP code actions cannot be run async (#95). Implementing this would thus make ruff more accessible to newcomers who just need to set one toggle instead of finding a workaround in the GitHub issues.

[charliermarsh]

Thanks! Are you imaging a dedicated code action for this, or a setting to make the format action do "everything"?

[chrisgrieser]

because of the drawbacks of code actions (e.g. no async), I think adding as an opt-in setting to formatting would be preferable?

[MichaReiser]

I can see how it makes sense to run organizeImport as part of formatting. In fact, we consider integrating organising imports into formatting into the CLI. Although VS Code identionally has a dedicated action for it. So it's a bit unclear if we want to keep the separation in IDEs or not.

I don't recommend integrating fix all into formatting. Fixing can create semantic changes. I would rather push for the opposite, considering to integrate format into fixAll. Again, this may be unexpected considering that many editors intentionally offer different actions for this. But we could expose different ruff.fixAll variations.

[chrisgrieser]

So it's a bit unclear if we want to keep the separation in IDEs or not.

I mean, making it an opt-in setting, leaving it to the user to decide cannot really hurt?

I don't recommend integrating fix all into formatting. Fixing can create semantic changes.

In my personal opinion, if something can introduce semantic changes, it should not have a fix code action to begin with, as it can easily mislead less experienced users?

I would rather push for the opposite, considering to integrate format into fixAll

In theory it does not make a difference which way to go, but using a code action instead of formatting has some disadvantages, such not being able to run async (see #93 for the problems this can entail).

[naddeoa]

I'm interested in a solution here as well. My current workflow has me using a nice keybind for running LspZeroFormat, which calls vim.lsp.buf.format() under the hood (usually after deleting a bunch of stuff) only to find a bunch of diagnostics I can't fix about unused imports, which I execute ruff check --fix to clean up.

I don't want to speak for what I think would be best for a certain type of user, but I know I'd love it if it all happened in a single command as someone who just compulsively spans format while refactoring.

[zanieb]

astral-sh/ruff#8232 is relevant here.

[nervenes]

any update on this?