Problems with code actions and jdtls language server

[niveK77pur]

Info

• Operating System: ArcoLinux

• Shell: Fish

• Terminal: wezterm

• nvim --version: NVIM v0.9.5

• fzf --version: 0.44.1 (29e67d30)

• [ ] The issue is reproducible with mini.sh

fzf-lua configuration

-- require('fzf-lua').setup({})
require('fzf-lua').register_ui_select()

My full config where I also tried disabling all configurations other than the one right above. Also tried disabling all other plugins to make sure the problem doesn't stem elsewhere.

Description

Code actions with jdtls are not working properly; meaning they either do not seem to trigger at all, or incorrectly modify the buffer and delete content. Simply disabling this plugin makes the code actions work as expected.

#314 seems related, but in this case it is precisely the register_ui_select that seems to be causing issues.

With fzf-lua's register_ui_select

Using the above configuration (only require('fzf-lua').register_ui_select())

video-Kazam_screencast_00001.webm

Without fzf-lua

Completlely disabling the plugin, removing the register_ui_select or calling require('fzf-lua').deregister_ui_select() will have the same effect.

video-Kazam_screencast_00000.webm

[ibhagwan]

nvim-jdtls works a bit differently, I’m not versed in Java, would you please peovide a few lines of Java code that should trigger an action so I can repeosuce this locally and fix it?

[niveK77pur]

Absolutely! I wouldn't say I'm versed enough to produce a proper example either, so I hope this will do. It is essentially the hello world generated from a gradle init. I somehow did not manage to get the LSP to provide anything useful with a standalone Java file, maybe I just don't know how to.

fzflua-java-codeaction-test.zip

There are few things that I know how to try on this one. Open the app/src/main/java/fzflua/java/codeaction/test/App.java. For reference, here is the file in question (from a cat -n).

     1  /*
     2   * This Java source file was generated by the Gradle 'init' task.
     3   */
     4  package fzflua.java.codeaction.test;
     5
     6  public class App {
     7    public String getGreeting1() {
     8      return "Hello World!";
     9    }
    10
    11    public String getGreeting2() {
    12      String string = "Hello World!";
    13      return string;
    14    }
    15
    16    public static void main(String[] args) {
    17      System.out.println(new App().getGreeting1());
    18      System.out.println(new App().getGreeting2());
    19    }
    20  }

• Line 8, put your cursor on the string and run one of the Extract to local variable actions. The diff in the preview shows the correct result but doesn't actually do anything.[^1]
• Line 13, put your cursor on the string variable and run one of the Inline local variable actions. Same problem as before.
• Line 12, put your cursor on the string variable and run the Change type of 'string' to 'var' action. It will turn String (the type) into varing which is not correct.
• Line 6, put your cursor on the class or App and run the Add Javadoc for 'App' action. It will erase a bunch of stuff from the line; I'd say the symptom is similar as in the previous point, and similar to the import action from my screencast.

---

In case it matters, I used gradle version 8.5 and java version openjdk 21 2023-09-19. I got jdtls via mason.

[^1]: I also just randomly noticed that an error is shown in the preview after a few seconds. It will be shown when you switch between actions. Using nvim-notify I actually get a notification with the exact same error once I attempt to run the code action (even if I run it before the error appears in the preview).

[deathbeam]

I had exactly same issue but what solved it for me is to switch the profile to fzf-tmux and since then the code actions are modifying buffer correctly. Its pretty weird as fzf-native had same issue as the default profile, just the tmux one worked.

[ibhagwan]

I had exactly same issue but what solved it for me is to switch the profile to fzf-tmux and since then the code actions are modifying buffer correctly. Its pretty weird as fzf-native had same issue as the default profile, just the tmux one worked.

@deathbeam, were you also using nvim-jdtls or another LSP server?

[deathbeam]

I had exactly same issue but what solved it for me is to switch the profile to fzf-tmux and since then the code actions are modifying buffer correctly. Its pretty weird as fzf-native had same issue as the default profile, just the tmux one worked.

@deathbeam, were you also using nvim-jdtls or another LSP server?

Yea, also nvim-jdtls (my dotfiles: https://github.com/deathbeam/dotfiles/blob/master/nvim/.config/nvim/init.lua)

[ibhagwan]

Ty @niveK77pur, @deathbeam - I was setup nvim-jdtls and able to reproduce this, I’m pretty sure the solution is straight forward, I’ll get deeper into it later when I have more time.

[ibhagwan]

At first glance this seems to be a bug in nvim-jdtls triggered by the previewer, when the code action requires resolving the previewer will send a codeAction/resolve request after which calling the ui.select on_choice callback fails with “Internal error”.

@deathbeam, the reason this was “solved” with “fzf-tmux” is because the profile doesn’t setup the correct code action previewer (should be codeaction_native, which I added after I added profiles and forgot to update the profile), due to the previewer not calling the resolve query the code action works.

Try FzfLua lsp_code_actions previewer=codeaction_native, the previewer will work but now the code action should fail.

[ibhagwan]

Unfortunately, this seems to be an upstream bug, I tried different workarounds none worked, the previewer calling codeAction/resolve seems to trigger the bug in the nvim-jdtls code, opened issue upstream: https://github.com/mfussenegger/nvim-jdtls/issues/608

As a workaround, disable the code action previewer, either by setup or:

:FzfLua lsp_code_actions previewer=false

[niveK77pur]

Awesome, thank you for the time to look into this! It would make sense if this issue is related with jdtls as I have never encountered such an problem with any other LSP so far!

Also as a small side note, I am not actually using nvim-jdtls but the symptoms that you mention in the upstream issue are identical to the ones I observed.

[ibhagwan]

Also as a small side note, I am not actually using nvim-jdtls but the symptoms that you mention in the upstream issue are identical to the ones I observed.

Than the issue probably needs to be opened with the eclipse LSP server itself?

[niveK77pur]

I have that hunch as well now. I commented on the other issue you opened, maybe there we'll come to the same conclusion.

[ibhagwan]

Closed the upstream issue with nvim-jdtls as this seems to be a bug in eclipse.

context: https://github.com/mfussenegger/nvim-jdtls/issues/608#issuecomment-1915347027

Upstream issue if you wish to track it: https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/376

Ty @deathbeam!

[ibhagwan]

FYI, thanks to @nabellows who found a workaround for this issue in #1057 this issue can be now closed.

[ibhagwan]

@deathbeam, can you check if this works for you as well, the solution is limited when the client name is jdtls and yours might be different: https://github.com/ibhagwan/fzf-lua/blob/903a4ae4e838170e4f44fb4ce1ca647a3c9cf828/lua/fzf-lua/previewer/codeaction.lua#L188-L194

Can you let me know what's the name of your lsp client by running this in a java buffer with the LSP active:

:lua print(vim.lsp.get_active_clients()[1].name)

[deathbeam]

:lua print(vim.lsp.get_active_clients()[1].name)

Does not work as my first client is copilot (from copilot.vim) and I get copilot from that lua command as output as well. And code action previewer is returning unsupported. This will be the case for everyone using copilot.vim most likely, easiest solution is to just filter it out I guess first.

[ibhagwan]

:lua print(vim.lsp.get_active_clients()[1].name)

Does not work as my first client is copilot (from copilot.vim) and I get copilot from that lua command as output as well. And code action previewer is returning unsupported. This will be the case for everyone using copilot.vim most likely, easiest solution is to just filter it out I guess first.

What does index 2 or 3 output? The client.name check in the code applies only to the matching code action so it shouldn’t be a problem, I just need to know the name of your Java LSP client.

[ibhagwan]

How about this @deathbeam:

:lua (function() for _, c in ipairs(vim.lsp.get_active_clients()) do print(c.name) end end)()

[deathbeam]

:lua print(vim.lsp.get_active_clients()[1].name)

Does not work as my first client is copilot (from copilot.vim) and I get copilot from that lua command as output as well. And code action previewer is returning unsupported. This will be the case for everyone using copilot.vim most likely, easiest solution is to just filter it out I guess first.

What does index 2 or 3 output? The client.name check in the code applies only to the matching code action so it shouldn’t be a problem, I just need to know the name of your Java LSP client.

jdtls. For full list:

But also i had issues with copilot.vim before reporting that it supports stuff that it doesnt so if the code relies on that.

And for the output of last command you sent:

copilot jdtls

[ibhagwan]

And for the output of last command you sent: copilot jdtls

Then the latest commit should solve the OP issue where jdtls actions aren't editing the workspace properly, can you check?

[deathbeam]

And for the output of last command you sent: copilot jdtls

Then the latest commit should solve the OP issue where jdtls actions aren't editing the workspace properly, can you check?

Oh yea, I misunderstood the question. Yes the edits are working, the previews arent. Unless thats expected (as I remember the previews showing in the past just the edits were messed up).

EDIT:

Actually I was on wrong branch, let check again

EDIT2:

Yes works my bad :d Was working on other PR and did not updated

[ibhagwan]

Yes the edits are working, the previews arent. Unless thats expected

Not all actions can resolve to workspace edits, that’s a function of the LSP server, if you play with it more you’d see some actions do resolve to edits and have previews.

[deathbeam]

Yes the edits are working, the previews arent. Unless thats expected

Not all actions can resolve to workspace edits, that’s a function of the LSP server, if you play with it more you’d see some actions do resolve to edits and have previews.

Yea now it works (and the edits too), very nice

[ibhagwan]

@deathbeam, highly recommend installing git-delta so it can look like this: