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
Unless these error codes are explicitly added to format they should not be automatically deleted.
So in case you don't want the error codes to not be fixed on file format, simply omit them from the format config setting.
I guess I was thinking about the fix all code action which would remove these. I don't want to ignore them because I do want to see the warnings, but I also don't want to delete them while editing.
I see, this can be done with no sweat. One question concerning the behavior in the presence of a pyproject.toml / ruff.toml: Should unfixable be ignored when a config is present?
We currently do not check for specific configuration settings in the pyproject.toml or ruff.toml but only check for their presence and consequently ignore some settings (see the README).
The remaining options are the ones that I believe to be always reasonable, things like which rules to fix when formatting (For example, formatting imports).
If we add unfixable to the options that are always taken from the LSP config, you may risk fixing issues deemed "unfixable" in the ruff.toml / pyproject.toml settings. That being said, I don't know any use case where you would want to deem a rule unfixable in one project only.
Happy to hear your take!
Activity
jhossbach commentedon Aug 14, 2025
Unless these error codes are explicitly added to
formatthey should not be automatically deleted.So in case you don't want the error codes to not be fixed on file format, simply omit them from the
formatconfig setting.rouge8 commentedon Aug 14, 2025
I guess I was thinking about the fix all code action which would remove these. I don't want to ignore them because I do want to see the warnings, but I also don't want to delete them while editing.
jhossbach commentedon Aug 14, 2025
I see, this can be done with no sweat. One question concerning the behavior in the presence of a pyproject.toml / ruff.toml: Should unfixable be ignored when a config is present?
We currently do not check for specific configuration settings in the pyproject.toml or ruff.toml but only check for their presence and consequently ignore some settings (see the README).
The remaining options are the ones that I believe to be always reasonable, things like which rules to fix when formatting (For example, formatting imports).
If we add unfixable to the options that are always taken from the LSP config, you may risk fixing issues deemed "unfixable" in the ruff.toml / pyproject.toml settings. That being said, I don't know any use case where you would want to deem a rule unfixable in one project only.
Happy to hear your take!
rouge8 commentedon Aug 14, 2025
I think unfixable in the LSP can override the project settings, just like a CLI flag would override the project settings.
jhossbach commentedon Sep 23, 2025
@rouge8 Sorry for the holdup! Can you checkout https://github.com/python-lsp/python-lsp-ruff/tree/add_unfixable and check if it works? The new setting is simply called
unfixable