fix: unable get expected altbuf

[fengwk]

In commit 365811e, 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.

[mfussenegger]

Can you explain how you produce the issue?

This looks pretty complex

[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]

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]

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.