-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vim.lsp.buf.format() invalidates changes list #21783
Comments
other vim features are affected too:
|
what can we do about that? |
you don't think that this is something neovim should handle? Looking at the lsp specification I'm not sure if this is actually prohibited. For example, one could compute the actual diff to the current buffer and then apply this as text edits. |
i mean yeah we could do that, or ... the language server could do that, since that is its job 😏 |
I noticed that if I use vim.lsp.buf.format in a lua file, the marks disappear. I found this issue and if I understood correctly there is a limitation in the lua language server---which indeed I don't have issues with python and other language servers. I'm wondering if there is any suggestion of a temporary workaround to avoid having the marks disappear for lua files when running the autoformating? EDIT: |
Describe the bug
I noticed that with some language servers (e.g. sumneko_lua) after calling
vim.lsp.buf.format()
entries in:changes
are marked as invalid (-invalid-
). This only seems to happen for lsp's sending the whole formatted document as response instead of actual text edits.Steps to reproduce
:lua vim.lsp.buf.format()
:changes
Expected behavior
calling
:changes
should result inbut instead shows
Neovim version (nvim -v)
v0.9.0-dev-581+gcb9d68fe6
Vim (not Nvim) behaves the same?
na
Operating system/version
5.15.0-10056-tuxedo
Terminal name/version
konsole 21.12.3
$TERM environment variable
xterm-256color
Installation
build from repo
The text was updated successfully, but these errors were encountered: