Issue previewing nvim-jdtls jdt:// entries in global/workspace symbols

[asmodeus812]

Info

• Operating System: WSL
• Shell: zsh
• Terminal: Windows terminal
• nvim --version: 0.9
• fzf --version: 0.39

Opening the previewer for workspace / global symbols and searching for say hashmap or collections, any of the standard java lib classes yields this error below. This was working fine before i updated fzf though, so not sure if its due to neovimd 0.9 or something changed in fzf recently.

require('fzf-lua').setup({
        keymap = {
            builtin = {
                -- for builtin previewer
                ["<C-d>"] = "preview-page-down",
                ["<C-u>"] = "preview-page-up",
            },
            fzf = {
                -- for fzf application
                ["enter"] = "accept",
                ["ctrl-a"] = "toggle-all",
                ["tab"] = "toggle+down",
                ["shift-tab"] = "toggle+up",
                -- for external fzf previewers
                -- ["<C-u>"] = "preview-page-up",
                -- ["<C-d>"] = "preview-page-down",
            },
        },
        actions = {
            files = {
                ["default"] = actions.file_edit_or_qf,
                ["ctrl-s"] = actions.file_split,
                ["ctrl-v"] = actions.file_vsplit,
                ["ctrl-t"] = actions.file_tabedit,
            },
            buffers = {
                ["default"] = actions.buf_edit_or_qf,
                ["ctrl-s"] = actions.buf_split,
                ["ctrl-v"] = actions.buf_vsplit,
                ["ctrl-t"] = actions.buf_tabedit,
            }
        },
        fzf_opts = {
            ['--history'] = history,
            ['--print-query'] = '',
            ['--info'] = 'inline',
            ['--height'] = '100%',
            ['--border'] = 'none',
        },
        files = {
            show_cwd_header = true
        },
        buffers = {
            show_cwd_header = true,
            ignore_current_buffer = true,
        },
        git = {
            show_cwd_header = true,
        },
        grep = {
            show_cwd_header = true,
            rg_opts = fzfcfg.globals.grep.rg_opts .. " --hidden",
            grep_opts = fzfcfg.globals.grep.grep_opts .. " --hidden",
        },
        lsp = {
            symbols = {
                symbol_style = 1,
                -- filter symbol types like class
                -- function, interface, struct etc
                regex_filter = "%[([SCMFDI].*)%].*",
            },
        },
})

Description

[ibhagwan]

This seems to be an issue related to nvim-jdtls, fzf-lua's call to vim.lsp.util.jump_to_location (with the jdt:// link) fails so the preview is unable to display the target buffer.

Is nvim-jdtls working properly otherwise? can you go to definitions/references/etc?

I tried reproducing this with nvim-jtdls but I'm having issues setting (it worked for me in the past) as described in mfussenegger/nvim-jdtls#459 (comment)

[ibhagwan]

@asmodeus812, it would also be helpful if you can find out when it broke exactly, maybe bisect nvim-jdtls/fzf-lua? Try with neovim 0.8.3 (or the last version it worked for you)?

I might be wrong but I have a feeling this issue stems from something other than fzf-lua.

[asmodeus812]

Any chance it could be mfussenegger/nvim-jdtls#453 ? Although i am using jt.ls 1.22

[ibhagwan]

Any chance it could be mfussenegger/nvim-jdtls#453 ? Although i am using jt.ls 1.22

I really can’t tell, never used Java, I only tried to install it for this issue.

[asmodeus812]

Seems to have been another plugin which was causing issues in the buffer. Unrelated.

@ibhagwan but on the same note, something strange that i noticed, while browsing workspace symbols (say HashMap.class form java util, opened as jdt:// resource) and if i have that one open and a vertical split with another class from local project open, if i open the go to symbols fzf picker and select a function or a symbol from the buffer / window where HashMap, is opened, the other split window (the local project window) is closed and i am left only with the HashMap window / buffer. Tried removing pretty much all relevant plugins, to no avail. Don't want to open a new issue though.

[ibhagwan]

@asmodeus812, that is probably because the previewer uses vim.lsp.util.jump_to_location to get to the contests of the jar file, I’ll have to test it (if I can get my nvim-jdtls setup to work again…) but my guess would be that nvim-jdtls reuses one buffer for the jar contained classes (similar to neovim help tags, :help always uses a single buffer) - if that’s the case I won’t be able to solve it without using nvim-jdtls internal code which I wish to avoid.

[asmodeus812]

I am not sure nvim jdtls even interfaces with symbols at all, but this recent change seems to change that mfussenegger/nvim-jdtls@f8fb45e#diff-cf51be59b2547129144014a9d62c2c686dece7eb590cd6a6f429cab5c58541c0. The autocmd is concerning me.

[ibhagwan]

I am not sure nvim jdtls even interfaces with symbols at all, but this recent change seems to change that mfussenegger/nvim-jdtls@f8fb45e#diff-cf51be59b2547129144014a9d62c2c686dece7eb590cd6a6f429cab5c58541c0. The autocmd is concerning me.

Any jdt:// link has to interact with nvim-jdtls to be able to be viewed, doesn’t matter where it’s sourced from, that would include symbols, that’s my understanding at least based on my limited testing with jdtls.

[asmodeus812]

I see, tried hard resetting to even older commit for jdtls - a71e656a553f0af306cffc81400f08dcedf295d6 like that one but still seeing the same issue

[ibhagwan]

I see, tried hard resetting to even older commit for jdtls - a71e656a553f0af306cffc81400f08dcedf295d6 like that one but still seeing the same issue

I’m not sure of there is a solution to this without changes to nvim-jdtls or having fzf-lua call an internal nvim-jdtls API that doesn’t reuse the buffer.

[ibhagwan]

You can test my theory by calling vim.lsp.util.jump_to_location('jdt://…', 'utf-8') while having a jdt link already open in a split and seeing if the buffer is reused.

[asmodeus812]

Not sure we are on the same page, even if the buffer i am currently looking pointing at a jdt:// resource at is getting reused (which is fine i don't mind it using the same buffer to jump somewhere else), the issue is why would it close all other windows/splits that i have open pointing at local files (buffers to those files are loaded, but windows get closed, all but the one with the jdt:// resource). I am trying to identify where it broke, i haven't had issues like that, the only change that springs to mind is upgrading to nvim 0.9, reverting both fzf-lua and jdtls to releases from 2 months ago does not fix the issue

Okay, reverted to 8.3, same issue, but here is an observation, if i have 3 horizontal splits, and have the jdt resource (opened from workspace_symbols) open in the middle one, if i navigate to a symbol (with document_symbols) within that one the split above the jdt:// split will get closed and the one below stays. So it does not close all windows, but something weird is going on, i did nuke pretty much all plugins away, save for lsp and fzf.

Can you think of Any other lsp that uses remote uri resources like that, to at least identify where the problem lies. Most refer to actual files on the file system and those cases work, the window layout is not getting fubar'd

[ibhagwan]

Not sure we are on the same page, even if the buffer i am currently looking pointing at a jdt:// resource at is getting reused (which is fine i don't mind it using the same buffer to jump somewhere else), the issue is why would it close all other windows/splits that i have open pointing at local files (buffers to those files are loaded, but windows get closed, all but the one with the jdt:// resource). I am trying to identify where it broke, i haven't had issues like that, the only change that springs to mind is upgrading to nvim 0.9, reverting both fzf-lua and jdtls to releases from 2 months ago does not fix the issue

Okay, reverted to 8.3, same issue, but here is an observation, if i have 3 horizontal splits, and have the jdt resource (opened from workspace_symbols) open in the middle one, if i navigate to a symbol (with document_symbols) within that one the split above the jdt:// split will get closed and the one below stays. So it does not close all windows, but something weird is going on, i did nuke pretty much all plugins away, save for lsp and fzf.

I’m unsure when this broke as I’m not a Java user but the only thing that differs with jdtls is the use of vim.lsp.util.jump_to_location in the preview, try any other language/LSP no this won’t happen so that would be my guess why this happens.

[asmodeus812]

@ibhagwan okay tried to use the native navigation without fzf-lua this time, the one that by default works with quickfix lists for symbols, that one navigates correctly it seems. Where / how it vim.lsp.util.jump_to_location used with fzf lua ?

[ibhagwan]

@ibhagwan okay tried to use the native navigation without fzf-lua this time, the one that by default works with quickfix lists for symbols, that one navigates correctly it seems. Where / how it vim.lsp.util.jump_to_location used with fzf lua ?

In order to view the contents of the jdt link, fzf-lua previewer will call jump to location, can you try with :FzfLua lsp_document_symbols previewer=false - this will prove (or disprove) my theory)?

[asmodeus812]

Okay here is another observation, with previewer, when i open the symbols picker and i don't move up or down, just immediately then it navigates in the same file without destroying the layout, which is what i would expect should happen.

Also note that when scrolling up/down (to force the issue) and the layout gets destroyed, it seems like the entire jdt://resource is getting read anew. There is significant delay between and the cursor being positioned at the location. I suspect maybe the buffer gets unlisted and resource read again.

With previewer = false, it does indeed work as expected, yes, you can scroll up or down and navigate to each one, and navigating to any symbol is fast as it used to be.

[ibhagwan]

Also note that when scrolling up/down (to force the issue) and the layout gets destroyed, it seems like the entire jdt://resource is getting read anew. There is significant delay between and the cursor being positioned at the location. I suspect maybe the buffer gets unlisted and resource read again.

There's not much I can do about this from fzf-lua's side, the only way I can consistently view internal jar file definitions is by calling jump_to_location and relying on nvim-jdtls to do the rest, buffer management is controlled by nvim-jdtls.

With previewer = false, it does indeed work as expected, yes, you can scroll up or down and navigate to each one, and navigating to any symbol is fast as it used to be.

Confirming my initial suspection this was jump_to_location, can you can try branch 728 which ignores all automds while performing the jump? This might solve it but may also create other issues if nvim-jdtls now relies on certain autocmds what will now not be executed.

Unfortuantely, I can't do much more than this, the rest will have to be dealth with via nvim-jdtls.

[asmodeus812]

That one sadly does not work, it jumps to the buffer but the events to decompile the jar do no trigger so the buffer is empty, the previewers however still show up the decompiled version .The change in that branch though seems to be on the action not the previewer ?

In order to view the contents of the jdt link, fzf-lua previewer will call jump to location

I am okay indeed, as long we understand the problem at hand at detail we can deal with it in nvim-jdtls, @mfussenegger

Unfortuantely, I can't do much more than this, the rest will have to be dealth with via nvim-jdtls.

Just to add something that could also be helpful (on master) with preview, when opening the split layout, and browsing for symbols in the jdt:// buffer, even an attempt to filter on those symbols in fzf in the list will result in the jdt window getting closed.

[ibhagwan]

The change in that branch though seems to be on the action not the previewer ?

Oops I did it in a rush from the mobile :-)

Can you pull rebase the branch and try again? but I suspect the previewer will be empty due to this:

it jumps to the buffer but the events to decompile the jar do no trigger so the buffer is empty

Just to add something that could also be helpful (on master) with preview, when opening the split layout, and browsing for symbols in the jdt:// buffer, even an attempt to filter on those symbols in fzf in the list will result in the jdt window getting closed.

This further confirms the unintended consequences of jump_to_location.

I am okay indeed, as long we understand the problem at hand at detail we can deal with it in nvim-jdtls, @mfussenegger

This is probably the best way forward, not much more I can do from fzf-lua's end.

[GiuseppeMP]

@ibhagwan

I configured the repro scenario in this repository using nvim-jdtls and fzf-lua, but I was unable to reproduce the issue.. May you try?

You only need a Java 17 installed and $JAVA_HOME setted to it, before running nvim -u repro.lua.

[ibhagwan]

@GiuseppeMP, as I mentioned in the other issue I am unable to setup nvim-jdtls, the client crashes so I can’t test any java LSP providers.

As for the issue in the OP, this only happens with Java class references that comes from nvim-jdtls, those are entries that start with jdt://…, I don’t see any of these in your screenshot, try references/definitions/etc.

[GiuseppeMP]

@GiuseppeMP, as I mentioned in the other issue I am unable to setup nvim-jdtls, the client crashes so I can’t test any java LSP providers.

As for the issue in the OP, this only happens with Java class references that comes from nvim-jdtls, those are entries that start with jdt://…, I don’t see any of these in your screenshot, try references/definitions/etc.

The repro.lua will install the jdtls and nvim-jdtls and configure them for you.

[ibhagwan]

The repro.lua will install the jdtls and nvim-jdtls and configure them for you.

I don’t have an issue with setup, I have an issue with the eclipse LSP client crashing, I’ll try the command inside your repo and see if that helps.

[ibhagwan]

Ty for the repo @GiuseppeMP, my java command seems to be the same yet mine doesn't work and yours work :-)

In any event, I wasn't able to reproduce the same issue with said jdt:// links, they do seem to open correctly:

However, scrolling between jdt:// links does raise an error (albeit different than the issue in the OP):

I'm going to try and fix my nvim-jdtls setup so I can solve this, ty!

[GiuseppeMP]

Ty for the repo @GiuseppeMP, my java command seems to be the same yet mine doesn't work and yours work :-)

In any event, I wasn't able to reproduce the same issue with said jdt:// links, they do seem to open correctly:

However, scrolling between jdt:// links does raise an error (albeit different than the issue in the OP):

I'm going to try and fix my nvim-jdtls setup so I can solve this, ty!

That's great! I'm glad that helped!

[ibhagwan]

ibhagwan/nvim-lua@680a381

@GiuseppeMP, FYI mfussenegger/nvim-jdtls#459 (comment), now I can finally solve this issue, ty :-)

[ibhagwan]

@asmodeus812 , @GiuseppeMP - latest commits should fix this.

Let me know if this solves it for you as well?

[GiuseppeMP]

@ibhagwan Works for me! 👏🏾

Before:

After:

[ibhagwan]

Fantastic, ty for the update @GiuseppeMP!

[mikehaertl]

So jdt:// preview still only works with the builtin previewer, is this correct?

Or is there any way to also make this work with FZF native previewer? I prefer the latter as it's way more snappy.

[ibhagwan]

So jdt:// preview still only works with the builtin previewer, is this correct?

Or is there any way to also make this work with FZF native previewer? I prefer the latter as it's way more snappy.

Unfortunately there not possible, previewing the jdt entries requires having nvim-jdtls installed and calling LSP go to location API which can’t work it’s an external binary.