Definition jump moves to line number in current file if buffer isn't saved
OJFord opened this issue · comments
Describe the bug
If the current buffer isn't saved, and not open in another split, LanguageClient#textDocument_definition()
is unable to load the file with the definition - which I suppose is desirable - but still then jumps to the definition line number, in the current buffer.
(This also affects LanguageClient#textDocument_references()
.)
Environment
-
neovim/vim version (
nvim --version
orvim --version
):
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 28 2021 06:58:52)
Included patches: 1-2891 -
This plugin version (
git rev-parse --short HEAD
):
a42594c -
This plugin's binary version (
bin/languageclient --version
): -
Minimal vimrc content (A minimal vimrc is the smallest vimrc that could
reproduce the issue. Refer to an example [here][min-vimrc.vim]):
N/A -
Language server link and version:
-
Pretty sure N/A, but pylsp v1.2.0
https://github.com/python-lsp/python-lsp-server
To Reproduce
- Open a file that calls a function defined in another on a different line number (examples below)
- Make some (any) edit, without saving (e.g. add whitespace to end of line in example)
- Place cursor on function (L3 in example)
:call LanguageClient#textDocument_definition()
# caller.py L1
if True:
fn()
# callee.py L1
def fn():
pass
Current behavior
Cursor jumps to line number of function definition (L2 in example), in current unsaved buffer (caller.py in example, not containing defn).
Expected behavior
Cursor doesn't move, (L3 in example) some error message.
Screenshots
N/A
Additional context
Try adding set hidden
to your vim config.
Setting that allows vim to hide buffers not currently attached to a window instead of unloading them (unloading them is destructive so it'll ask you to confirm, I think you are running up against this in a weird way when the plugin tries to swap buffer).
I think I'd rather keep the behaviour of 'where are you going, you haven't saved' though; it just shouldn't jump to line as though the buffer's changed. (If it's large and the line number is very different, then it's not immediately apparent that it wasn't successful, it's just confusingly not what you searched for.)