I recently made an attempt to switch my code editor from vscode to emacs, where I discovered things like language server protocols being used to provide syntax highlighting and code completion features.
However, when I tried to find a rename symbol functionality, I found that emacs only renamed symbols in open buffers using lsp-rename, whereas vscode was able to replace symbol across all files in the open folder/project.
This has intrigued me and has made me wonder how does this functionality work internally in vscode? How does vscode detect and solve symbol ambiguities (same symbol name in different namespaces for example) and why lsp-rename is different than vscode symbol renaming?
(For some context, I was working on the same rust project in both editors and was using rust-analyzer as lsp in both editors)
2
Answers
After experimenting with the rust-analyzer LSP on different editors (Neovim, VSCode, doom-emacs), I found the LSP features working correctly on editors like VSCode and Neovim (I used prebuilt neovim configs such as lazyvim and astrovim, with some additional lua plugins), so I don't think that vscode is adding anything extra to the lsp based operations in the editor.
My best guess is that the Emacs lsp-rename binding to the LSP does not properly integrate with modern LSP interfaces, which must be resulting in different behaviour in the Emacs editor.
It’s up to whatever language-support extension implements the refactoring. VS Code provides two ways for a language-support extension to provide refactoring rename support: either using the VS Code extension
languages.*
API, or by writing a language server.For the
language.*
API, seeregisterRenameProvider(selector: DocumentSelector, provider: RenameProvider): Disposable
:Also see the API docs for
RenameProvider
.For the Language Server route, see
textDocument.rename
andtextDocument.prepareRename
.See also https://code.visualstudio.com/api/language-extensions/programmatic-language-features#language-features-listing.