Discard results of long-running 'goto definition' requests

[susliko]

Describe the bug

I've been noticing the following behaviour when Metals is just starting or the code was not yet compiled before:

1. Invoke 'goto definition' lsp request on a symbol under the cursor
2. Wait a little
3. Start doing something else in another buffer
4. Receive a response to that 'goto definition' request accompanied with a buffer switch in the active window

Expected behavior

Buffer is not switched to the one from the 'goto definition' response if active nvim buffer is not the same as at the time of request invocation

Operating system

macOS

Version of Metals

v0.11.9

Commit of nvim-metals

0b9c530

[ckipp01]

Hey @susliko, thanks for opening this. This is a tricky one. At least in nvim-world I'm assuming that since the server attached to your current buffer is the same as the other, the goto definition handler just handles it. You can see this here. So at least in nvim-metals unless we would want to override the handler (which I don't), there isn't really a good way to discard it. Another option might be to try and send a cancel if you move out of the buffer, but that's also probably not ideal on the client side to have to check that all the time.

@tgodzik do you know if VS Code behaves the same if you trigger a goto definition and then move to another file? What happens when the response comes back?

@susliko I'd recommend bringing this up in the Neovim matrix channel or creating an issue over there to see what the desired behavior should/could be. I'm assuming that this is a bit unique to Scala though seeing that when you first open a workspace it can take a second to index.

[tgodzik]

do you know if VS Code behaves the same if you trigger a goto definition and then move to another file? What happens when the response comes back?

Just as mentioned on the contributors chat, looks like if you change to another file the go to definition will be cancelled, or really once you do another thing in the file.