python-language-server Cannot LspRename

I have filed https://github.com/prabirshrestha/vim-lsp/issues/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?

Jan 05 '18 11:01 mcepl

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.

Jan 09 '18 23:01 gatesn

@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?

Jan 10 '18 03:01 prabirshrestha

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.

Jan 10 '18 09:01 mcepl

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

Jan 10 '18 09:01 gatesn

pyls-log.txt and vim-lsp.log

Jan 10 '18 10:01 mcepl

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

Jan 10 '18 11:01 gatesn

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

Feb 17 '18 14:02 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.

Feb 17 '18 14:02 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.

Feb 19 '18 16:02 mcepl

Any updates? Still experiencing this issue with autozimu/LanguageClient-neovim https://github.com/autozimu/LanguageClient-neovim/issues/46

May 04 '18 15:05 Congee

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

May 05 '18 07:05 CSRaghunandan

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.

May 07 '18 18:05 abingham

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

Jun 13 '18 13:06 wyuenho

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.