Closed asmodeus812 closed 1 year ago
I don't really see how this could be an jdtls issue.
All nvim-jdtls is define a BufReadCmd
:
au BufReadCmd jdt://* lua require('jdtls').open_classfile(vim.fn.expand('<amatch>'))
au BufReadCmd *.class lua require("jdtls").open_classfile(vim.fn.expand("<amatch>"))
and open_classfile
queries the language server for the content and adds it to the buffer.
If that doesn't work with fzf-lua, I assume it in general has problems with custom BufReadCmd
autocmds.
Indeed probably something to do with the way the class contents are populated or the view buffer is used, @ibhagwan and i talked about in the linked issue above, and that is why as he suggested i cross posted the issue, so we can take a look at what is going on, it is certainly an interaction between both, but i can't tell why either.
Does the problem also reproduce with something like this:
api.nvim_create_autocmd("BufReadCmd", {
pattern = "foo://*",
callback = function()
local bufnr = api.nvim_get_current_buf()
vim.bo[bufnr].modifiable = true
vim.bo[bufnr].swapfile = false
vim.bo[bufnr].buftype = 'nofile'
api.nvim_buf_set_lines(bufnr, 0, -1, true, {"dummy", "content"})
vim.bo[bufnr].modifiable = false
end
})
And then opening foo://dummy
?
Unfortunately I am unable to attempt to fix this issue due to a startup crash of jdtls as described here https://github.com/mfussenegger/nvim-jdtls/issues/459#issuecomment-1517944867
It seems I’m not the only one experiencing this, never used Java before just installed it in order to tackle this issue but can’t get any further. It’s worth mentioning that the same setup worked in the past, when first adding support for nvim-jdtls previews.
After fixing my jdtls
setup I believe was able to fix the issues described in the OP in https://github.com/ibhagwan/fzf-lua/commit/9d9eea43c4e94268e22f1bb5d7cbff7c98f81300.
@asmodeus812 try the latest commit and let me know?
LSP client configuration
Hi, wanted to share how great nvim-jdtls has been recently, but i have noticed that two issues have popped up recently i think are related to the de compilation of the class files with fzf-lua's default builtin previewer. One of the issues is related to missing / invalid window handle error when working with lsp_workspace_symbols the other one is related to lsp_document symbols. Below i have tried to explain the issues and referenced the issue in the fzf-lua repo to reproduce it. I suspect the issue has something to do with the way we handle the jdt:// resources in the current buffer but not well versed with jdtls to know exactly what is going on.
Eclipse.jdt.ls version
1.22
Steps to Reproduce
lsp_workspace_symbols
lsp_document_symbols
NOTE: if instead of filtering, we select the first entry the other split windows are not getting closed, the issue was discussed here https://github.com/ibhagwan/fzf-lua/issues/728#issuecomment-1518684511
Expected Result
No issues from both use cases should be observed. I can confirm that other language servers do not exhibit this issue. Tagging @ibhagwan for reference.
Actual Result
Described above, but the basic gist - document_symbols fails to navigate to the selected symbol, workspace_symbols throws error with invalid window handle.