nvim-jdtls icon indicating copy to clipboard operation
nvim-jdtls copied to clipboard

fix: unable get expected altbuf

Open fengwk opened this issue 2 years ago • 3 comments

In commit 365811ecf97a08d0e2055fba210d65017344fd15, we inferred the altbuf. However, there are two issues:

  1. bufnr([{buf} [, {create}]]) - The second parameter 'create' in bufnr([{buf} [, {create}]]) cannot be set to a value, as it will create a new buffer when no previous buffer exists.
  2. When I execute lsp_util.locations_to_items in the jdt:// buffer, other jdt:// locations will be parsed. However, at this point, I cannot retrieve the previous buffer using bufnr('#'). The return value will be -1.

Therefore, I want to manage the latest accessed buffer associated with jdtls. I will record the latest buffer at on_attach and BufEnter.

fengwk avatar Jun 05 '23 12:06 fengwk

This happens when two jdtls LSPs are opened simultaneously, and the following steps may be able to reproduce this situation:

  1. First, open a file from Project A, which initiates the LSP for Project A.
  2. Open a file from Project B, which initiates the LSP for Project B.
  3. Navigate from the open position in Project B to a source file that is not in the current project, which will load this file into the LSP for Project B via the jdt:// protocol.
  4. Then, use jump_to_location in the position of Project B to jump again, for instance, by executing vim.lsp.buf.definition to navigate to another source file that is not in the current project. This will also load the file via the jdt:// protocol. At this point, obtaining altbuf becomes invalid, leading to incorrect binding of the LSP.

As I do not fully understand the internal implementation mechanism of vim.lsp, I have thought of a compromise solution where I can manage the LSP file of the most recent plan myself to avoid this case.

fengwk avatar Jun 23 '23 14:06 fengwk

I need to further elaborate on the impact of this issue. If the LSP of Project A does not have the corresponding file, the jump will fail. In my case, both Projects A and B rely on the same version, but the LSP loaded the wrong version. As a result, I discovered the issue of incorrectly binding the buffer to the LSP.

fengwk avatar Jun 23 '23 14:06 fengwk

Another reason for the commit "fix: modify the method of obtaining ft to respond to bad cases" is that I noticed that sometimes vim.bo[bufnr].filetype == "java" doesn't work as expected, but vim.api.nvim_buf_get_option(bufnr, "filetype") always returns the desired result.

fengwk avatar Jun 23 '23 14:06 fengwk