autozimu / LanguageClient-neovim

Language Server Protocol (LSP) support for vim and neovim.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 or vim --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

  1. Open a file that calls a function defined in another on a different line number (examples below)
  2. Make some (any) edit, without saving (e.g. add whitespace to end of line in example)
  3. Place cursor on function (L3 in example)
  4. :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.)