fix: unable get expected altbuf
In commit 365811ecf97a08d0e2055fba210d65017344fd15, we inferred the altbuf. However, there are two issues:
bufnr([{buf} [, {create}]])- The second parameter 'create' inbufnr([{buf} [, {create}]])cannot be set to a value, as it will create a new buffer when no previous buffer exists.- When I execute
lsp_util.locations_to_itemsin thejdt://buffer, otherjdt://locations will be parsed. However, at this point, I cannot retrieve the previous buffer usingbufnr('#'). 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.
This happens when two jdtls LSPs are opened simultaneously, and the following steps may be able to reproduce this situation:
- First, open a file from Project A, which initiates the LSP for Project A.
- Open a file from Project B, which initiates the LSP for Project B.
- 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.
- 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.
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.
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.