search

mfussenegger / nvim-jdtls

Extensions for the built-in LSP support in Neovim for eclipse.jdt.ls
GNU General Public License v3.0
1.05k stars 61 forks source link

fix: unable get expected altbuf #501

Open fengwk opened 1 year ago

fengwk commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.