-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with code actions and jdtls language server #1007
Comments
|
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 fzflua-java-codeaction-test.zip There are few things that I know how to try on this one. Open the 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 }
In case it matters, I used gradle version 8.5 and java version openjdk 21 2023-09-19. I got jdtls via mason. Footnotes
|
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) |
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. |
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 @deathbeam, the reason this was “solved” with “fzf-tmux” is because the profile doesn’t setup the correct code action previewer (should be Try |
Unfortunately, this seems to be an upstream bug, I tried different workarounds none worked, the previewer calling As a workaround, disable the code action previewer, either by setup or: :FzfLua lsp_code_actions previewer=false |
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. |
Than the issue probably needs to be opened with the eclipse LSP server itself? |
I have that hunch as well now. I commented on the other issue you opened, maybe there we'll come to the same conclusion. |
Closed the upstream issue with context: mfussenegger/nvim-jdtls#608 (comment) Upstream issue if you wish to track it: eclipse-jdtls/eclipse.jdt.ls#376 Ty @deathbeam! |
FYI, thanks to @nabellows who found a workaround for this issue in #1057 this issue can be now closed. |
@deathbeam, can you check if this works for you as well, the solution is limited when the client name is fzf-lua/lua/fzf-lua/previewer/codeaction.lua Lines 188 to 194 in 903a4ae
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) |
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. |
How about this @deathbeam: :lua (function() for _, c in ipairs(vim.lsp.get_active_clients()) do print(c.name) end end)() |
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 |
Then the latest commit should solve the OP issue where |
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, highly recommend installing git-delta so it can look like this: |
Info
Operating System: ArcoLinux
Shell: Fish
Terminal: wezterm
nvim --version
: NVIM v0.9.5fzf --version
: 0.44.1 (29e67d30)The issue is reproducible with
mini.sh
fzf-lua configuration
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 callingrequire('fzf-lua').deregister_ui_select()
will have the same effect.video-Kazam_screencast_00000.webm
The text was updated successfully, but these errors were encountered: