Cannot LspRename

[mcepl]

I have filed prabirshrestha/vim-lsp#61 but the maintainer there (@prabirshrestha) closed the bug on me blaming the server. Even when I upgraded python-language-server to the last release (0.12.1) I get the same reaction (this is the log): no error, but no change in the editor.

Using vim 8, python 3.4, on RHEL-7.

Any ideas, what's wrong?

[gatesn]

Are you able to get me the stderr of the python language server? Seems like the log you linked just includes the vim-lsp logs.

[prabirshrestha]

@mcepl Can you update the log with verbose to enable stderr messages. let g:lsp_log_verbose = 1
@gatesn For me even log verbose didn't show any messages. Is there a way to force pyls to use its own log file?

[mcepl]

Can you update the log with verbose to enable stderr messages. let g:lsp_log_verbose = 1

I have let g:lsp_log_verbose = 1 in my ~/.vim/vimrc.

So, I tried to add this to the configuration in ~/.vim/vimrc:

if executable('pyls')
    " pip install python-language-server
    au User lsp_setup call lsp#register_server({
        \ 'name': 'pyls',
        \ 'cmd': {server_info->['pyls', '--verbose', '--log-file', '/tmp/pyls-log.txt']},
        \ 'whitelist': ['python'],
        \ })
endif

And attached is both pyls-log.txt and vim-lsp.log.

[gatesn]

@mcepl could you try pyls -vv --log-file ... that should get debug messages from pyls.

[mcepl]

pyls-log.txt and vim-lsp.log

[gatesn]

That's really weird, the pyls log just stops abruptly, and the vim log claims python exited 1. I'll try and reproduce

[mcepl]

Still doesn’t work even with python-language-server 0.14.0, latest vim-lsp and vim 8.0.1520.

[mcepl]

A strange thing is that I cannot rename that attribute even with VSCode (1.20.1-1518536126, ms-python.python 2018.1), does it use this language server as well (but some its private copy, right? Not the pyls available in $PATH, right)? However, with VSCode I can rename variable res on line 34 (which I cannot do with vim).

I am not sure, where to find debugging logs from VSCode, vim ones are pyls-log.txt and vim-lsp.log.

[mcepl]

When trying to use autozimu/LanguageClient-neovim (with vim8), I get same results like with VS Code (I can rename res, but not self.provider_type). Logs are again not very persuasive.

[Congee]

Any updates? Still experiencing this issue with autozimu/LanguageClient-neovim autozimu/LanguageClient-neovim#46

[CSRaghunandan]

I'm also running into errors when I try to rename using the lsp-mode in emacs.

[abingham]

I'm also running into errors when I try to rename using the lsp-mode in emacs.

This appears to be a result of a) how line numbers get serialized and b) the types that lsp-mode expects. For rename, pyls is returning sys.maxsize for the end line, and - at least when it gets to emacs lisp via stdout - that values is serialized in "scientific notation" (e.g. 9.2e+18). lsp-mode ultimately passes this to forward-line which expects and integer but, unfortunately, this is a floating point value.

[wyuenho]

Renaming now works for me on Emacs, but it's really really slow.

[dlukes]

My experience is that rename sometimes works, and sometimes doesn't. When it doesn't, my LSP client informs me that there has been a timeout.

I dug around a little bit and it seems that the rope library (which is doing the renaming under the hood) just sometimes takes a really long time to compute the necessary changes, i.e. run the rope.refactor.rename.Rename.get_changes() method.

I tried dill-pickling the Rename object created by one of these rename operations which time out and calling its get_changes() method manually from an interactive session, and it does complete successfully, it just takes a while.

I noticed this tends to happen when trying to rename in ad-hoc scripts which live in directories alongside a lot of other (possibly unrelated) stuff. In conventionally structured projects (libraries, apps), it tends to work fine, especially if they're on the smallish side.

A workaround if you're writing an ad-hoc script is to place it in a directory on its own, then refactoring should be speedy, at least according to my experience.