You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Surface Ruff auto-fix capabilities as Quick Fix actions #3
I don't think pylsp supports quick fix actions but it supports documentFormatting. On that side note, we need to add --no-fix to the ruff call for linting because otherwise ruff will return the new file instead of json dict with diagnostics.
On that side note, we need to add --no-fix to the ruff call for linting because otherwise ruff will return the new file instead of json dict with diagnostics.
If I understand correctly, then in the future it is planned for the plugin to provided fixes from ruff as lsp actions, right?
That'd be great! since, if I'm correct, python-lsp-server and most of other plugins don't provide functionality for that (ex. simple stuff like removing trailing whitespaces, etc), and it's very tiresome to fix all that stuff by hand when it could easily be done by the lsp.
I have been letting it slide for a while since there seemed to be not much of interest, but I can start implementing it now. Should this be done when applying textDocument/formatting or should it be textDocument/codeAction only?
I think it should be implemented as code actions, not auto-formatting, so that users can opt in into the suggested fixes.
Furthermore, I think most people understand auto-formatting as providing purely stylistic rewriting to make the code look better, not actual changes without their consent.
Activity
jhossbach commentedon Dec 11, 2022
I don't think pylsp supports quick fix actions but it supports
documentFormatting. On that side note, we need to add--no-fixto the ruff call for linting because otherwise ruff will return the new file instead of json dict with diagnostics.jhossbach commentedon Dec 11, 2022
Actually, I just went through the log of pylsp and found this:
It at least says that codeactions are available, but I need to look into that.
ccordoba12 commentedon Dec 11, 2022
I think it does, they are called code actions. For example, they are used by pylsp-rope.
jhossbach commentedon Dec 11, 2022
Can we add it as a feature to https://github.com/python-lsp/python-lsp-server#lsp-server-features?
charliermarsh commentedon Dec 11, 2022
Yeah sorry, I believe Quick Fix is a “kind” of Code Action.
ccordoba12 commentedon Dec 11, 2022
Sure, please open a pull request for that and I'll merge it.
charliermarsh commentedon Dec 11, 2022
Yeah we should pass
--no-fix, that sounds right.0rphee commentedon Feb 10, 2023
If I understand correctly, then in the future it is planned for the plugin to provided fixes from ruff as lsp actions, right?
That'd be great! since, if I'm correct,
python-lsp-serverand most of other plugins don't provide functionality for that (ex. simple stuff like removing trailing whitespaces, etc), and it's very tiresome to fix all that stuff by hand when it could easily be done by the lsp.jhossbach commentedon Feb 10, 2023
I have been letting it slide for a while since there seemed to be not much of interest, but I can start implementing it now. Should this be done when applying
textDocument/formattingor should it betextDocument/codeActiononly?ccordoba12 commentedon Feb 10, 2023
I think it should be implemented as code actions, not auto-formatting, so that users can opt in into the suggested fixes.
Furthermore, I think most people understand auto-formatting as providing purely stylistic rewriting to make the code look better, not actual changes without their consent.
jhossbach commentedon Feb 10, 2023
I agree 👍 I wonder though, are there any methods in the lsp reference to apply all code actions?
ccordoba12 commentedon Feb 10, 2023
Don't know about that, sorry.
0rphee commentedon Feb 11, 2023
I don't know much about lsp's but if it is of any help, this is an example of what hls (the haskell lsp) does in that regard :)
betaboon commentedon Mar 19, 2023
fyi: i started implementing this in #22