You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After doing an LspRename, if the rename affects an unopened buffer, vim-lsp loses file synchronization with pylsp. So we start by renaming a variable in file moda.py, which imports a variable from modb.py; when we do the rename twice in a row, the second rename fails.
I've been reading through the logs and running debugger on the LSP (pylsp), I think the root cause of this issue seems te be vim-lsp and pylsp not agreeing who is controlling a file. When rope tries to read the modb.py from the workspace for the second rename operation, pylsp does not have the current state of the file, so pylsp reads the file from the filesystem which contains an older version of modb.py, but reads moda.py from the client as it is opened by the LSP client. Since modb.py already has unsaved changes from the previous rename command, modb.py should've been read from the client. I'm not familiar enough with the file synchronization mechanism in LSP, but I'm not quite sure who is supposed to own the file at this point.
Setup
Make sure vim is NOT configured to autosave files.
Setup a python venv, use the pylsp_rope rename plugin from pylsp-rope from this pull request. The builtin jedi_rename and rope_rename plugin should be disabled:
Open moda.py, point the cursor to three. :LspRename the variable three to four. This rename should successfully modify both moda.py and modb.py correctly in-buffer.
Without saving, quitting vim, or switching tabs, :LspRename the variable four to five. This would only modify moda.py, but not modb.py.
LSP server is python-lsp-server==1.10.0 with the pylsp_rope rename plugin from this pull request.
The text was updated successfully, but these errors were encountered:
lieryan
changed the title
File ownership state is out of sync when LspRename-ing on unsaved buffer
File ownership state is out of sync when LspRename-ing on unsaved buffer on multiple files
Mar 12, 2024
lieryan
changed the title
File ownership state is out of sync when LspRename-ing on unsaved buffer on multiple files
File ownership state is out of sync when doing multiple LspRename on unsaved buffers on multiple files
Mar 12, 2024
Summary
After doing an LspRename, if the rename affects an unopened buffer, vim-lsp loses file synchronization with pylsp. So we start by renaming a variable in file
moda.py
, which imports a variable frommodb.py
; when we do the rename twice in a row, the second rename fails.I've been reading through the logs and running debugger on the LSP (pylsp), I think the root cause of this issue seems te be vim-lsp and pylsp not agreeing who is controlling a file. When rope tries to read the
modb.py
from the workspace for the second rename operation, pylsp does not have the current state of the file, so pylsp reads the file from the filesystem which contains an older version ofmodb.py
, but readsmoda.py
from the client as it is opened by the LSP client. Sincemodb.py
already has unsaved changes from the previous rename command,modb.py
should've been read from the client. I'm not familiar enough with the file synchronization mechanism in LSP, but I'm not quite sure who is supposed to own the file at this point.Setup
Make sure vim is NOT configured to autosave files.
Setup a python venv, use the pylsp_rope rename plugin from pylsp-rope from this pull request. The builtin jedi_rename and rope_rename plugin should be disabled:
$ python3 -m venv pylsp-venv $ source pylsp-venv/bin/activate $ pip install -e git+https://github.com/python-rope/pylsp-rope.git@lieryan-implement-rename#egg=pylsp-rope
Minimal ~/.vimrc:
Reproduce
Create two files:
Open moda.py, point the cursor to
three
.:LspRename
the variablethree
tofour
. This rename should successfully modify both moda.py and modb.py correctly in-buffer.Without saving, quitting vim, or switching tabs,
:LspRename
the variablefour
tofive
. This would only modifymoda.py
, but notmodb.py
.LSP server is
python-lsp-server==1.10.0
with the pylsp_rope rename plugin from this pull request.Client capabilities
Server Capabilities
Server Configuration
Additional info
The logs are too long for Github, so I am attaching them as Gist.
The text was updated successfully, but these errors were encountered: