implement `didRenameFiles`
rebelot opened this issue · comments
I came up with this, it would be great if that was handled by default :)
EDIT: fix wrong implementation and add WillRenameNode
local function make_rename_params(old_fname, new_fname)
return {
files = {
{
oldUri = vim.uri_from_fname(old_fname),
newUri = vim.uri_from_fname(new_fname),
},
},
}
end
local Event = api.events.Event
api.events.subscribe(Event.NodeRenamed, function(data)
local clients = vim.lsp.get_active_clients()
local params = make_rename_params(data.old_name, data.new_name)
for _, client in ipairs(clients) do
local didRename = vim.tbl_get(client, "server_capabilities", "workspace", "fileOperations", "didRename")
if didRename ~= nil then
client.notify("workspace/didRenameFiles", params)
end
end
end)
api.events.subscribe(Event.WillRenameNode, function(data)
local clients = vim.lsp.get_active_clients()
local params = make_rename_params(data.old_name, data.new_name)
for _, client in ipairs(clients) do
local willRename = vim.tbl_get(client, "server_capabilities", "workspace", "fileOperations", "willRename")
if willRename ~= nil then
local resp = client.request_sync("workspace/willRenameFiles", params, 1000)
if resp and resp.result ~= nil then
vim.lsp.util.apply_workspace_edit(resp.result, client.offset_encoding)
end
end
end
end)
Or could be added to https://github.com/antosha417/nvim-lsp-file-operations instead?
great! I didn't know about https://github.com/antosha417/nvim-lsp-file-operations.
I edited my previous snippet that effectively supersedes the use of an external plugin
That plugin is rather nice. We have it listed at wiki: Extension Plugins however we might like to add those to help or readme.
Confirming: does that meet your needs @rebelot ?
all good :)
Big thanks to @susliko for creating that extension.
The separation of responsibilities is fantastic.
I am starting to think that perhaps bundling those handlers would be pretty beneficial for wider audience.
@alex-courtis Would you really be against merging it if @rebelot's solution was morphed into PR? I definitely understand separation of concerns here but maybe benefit outweighs cost in this case?
I am starting to think that perhaps bundling those handlers would be pretty beneficial for wider audience.
@alex-courtis Would you really be against merging it if @rebelot's solution was morphed into PR? I definitely understand separation of concerns here but maybe benefit outweighs cost in this case?
I'm very much in favour of adding events - whatever is missing and would be useful for nvim-lsp-file-operations and other use cases.
It's not quite clear exactly what we need to implement here; the NodeRenamed event could be added to nvim-lsp-file-operations as per WillRenameNode. I might be missing something here: your insight would be appreciated @susliko
IMHO I think it would be better if nvim tree handled this natively w/o external plugin for a nice OOB experience
IMHO I think it would be better if nvim tree handled this natively w/o external plugin for a nice OOB experience
Is there a use case that the extension does not provide?
Not really except needing another plugin which was not easily discoverable. I installed nvim-tree a long ago and I don't routinely check the the wiki for new features. Although I carefully read update commits.
I guess question to answer here is whether having discussed functionality in separate plugin benefits other plugins (acting as kind of lib) or not. If others can take advantage of separate plugin then it makes sense to keep it there and not replicate code here, otherwise it would indeed provide better out of the box experience.
@antosha417 would be interesting to hear your opinion on above comment.
Sorry for a long time it took to reply
@rebelot Just being curious, do you know any language servers that support the didRenameFiles notification? I've only seen them implement willRenameFiles request. It's somewhat more practical as it enables implementations for preview windows of changes with options for picking only a subset of changes or not applying them at all (e.g. VSCode does this)
@gegoune @alex-courtis
Not sure that backing-in lsp manipulations into the file-tree plugin is the best way to go
Pros:
- convenience for some group of users
Cons:
- there might be integrations with other file-tree plugins (e.g. neo-tree requested here)
- we might want to implement aforementioned previews
Not sure that backing-in lsp manipulations into the file-tree plugin is the best way to go
The cons do indeed outweigh the pro.
we might want to implement aforementioned previews
This could be implemented via api.node.open.preview and be hooked into nvim-tree, neo-tree, *-tree
@rebelot This improvement while cool, does not really cover more than the most obvious / easy case, you still have operations which are also willRename such as - cut/paste action, we also have (bulk) move action, then the other types of resource provisioning like willCreate and willDelete also need to be added as events. Maybe there are other which i am missing which can also in the end be interpreted down to the basic 3 - rename, create or delete.