No code actions available when hovered over certain warnings

[patrickarmengol]

When hovering over certain warnings, like F401, no code actions are available. This seems to be unintended as the first example gif in the readme (https://github.com/charliermarsh/ruff-lsp#quick-fix-actions-for-auto-fixable-violations-like-unused-imports) shows available code actions when hovering F401.

Environment: neovim 0.9.0, ruff-lsp 0.0.24

Steps to reproduce:

1. Open a python file
2. Scroll over or write in an unused import to create a F401 warning.
3. Try to call code actions :lua =vim.lsp.buf.code_action()

Another diagnostic code that causes this issue is F821(undefined name). Per #91 (comment) this may affect quite a few more types of warnings.

[charliermarsh]

I just tested this locally in Neovim and it worked correctly for me with v0.8.1, AFAICT:

I'll try upgrading to 0.9.0.

[charliermarsh]

Hmm, ok, still seems to work on 0.9.0. Do you have other plugins installed, anything else that could be impacting this?

[patrickarmengol]

Hmm, ok, still seems to work on 0.9.0. Do you have other plugins installed, anything else that could be impacting this?

Not sure what it could be. I disabled pyright that was running beside it. I commented out the ruff-lsp lines from lspconfig.

Just to give some background, I'm running astronvim. The base config files for lsp stuff (utils/lsp.lua and plugins/configs/lspconfig.lua) don't seem to reveal anything that could be causing this (at least to my eyes).

Another user on the astronvim discord reported the same issue too, so perhaps it's an "us" problem.

Though I wonder why #91 (comment) ran into the same problem.

I'll try to mess around a bit more to isolate it.

[patrickarmengol]

Ok, looks like I messed up when choosing an example warning to represent the issue as F401 was marked under unfixable in the ruff settings for the default hatch-generated pyproject.toml.

Still, this occurs for other non-fixable warnings like:

F821 (undefined name)

F704 (yield outside function):

[charliermarsh]

Ah no worries. I think those two errors aren't actually fixable though, so it seems right for there to be no code actions available.

[patrickarmengol]

Ah no worries. I think those two errors aren't actually fixable though, so it seems right for there to be no code actions available.

Should file-wide actions (like fix-all and org-imports) still be unavailable though? They are available on empty lines and other unrelated fixable warnings. Sorry I'm not sure how code actions for other LSPs usually work.

[charliermarsh]

Oh, hmm, maybe? I'd say yes? But I'm not 100% certain either, it could vary from client to client, but I'm confused as to why it would suppress them there.

[patrickarmengol]

I'm coming from VSCode, where the actions are available in such situations, so I thought it was strange. Also ran into it when testing out performing code actions on save in order to auto-sort imports in nvim. IMO they should be available, but not sure how to do so for nvim. Feel free to close this issue, unless you think it could be fixed from the language server side and not the client. Thanks.

[burnettk]

I took the time to create a minimal repro for an issue that I saw that may be an example of this: https://github.com/burnettk/assorted-repro-scenarios/tree/main/ruff-lsp-bug-repro. Basically, with the following code, even though there are linting issues on both lines. there are no code actions for line 1, but there are code actions for line 2:

def sureEnough():
    a = 1
    print("I'm sure")

sureEnough()

[dhruvmanila]

I'm pretty confident it's the same issue: #128

It should be fixed on HEAD. Let me do a quick test with the examples mentioned in this issue. @charliermarsh we would probably need to make a patch release.

[dhruvmanila]

Yeah, it's the same issue. It's fixed with #129