Mini Files lsp integration.

[231tr0n]

Hi @echasnovski! Sorry for the ping again. I just realized mini.files does not have support for willdeletefiles, willcreatefiles and willrenamefiles requests for lsp. I just implemented this small snippet to make this happen. The issue I am facing here is that before calling didmethods, willmethods should be called and that too before the changes are made, and I needed a way to get the changes done by mini.files before they are done and once they are confirmed. I just tried looking at the autocommands and non of them seem to help. So Is there any way to expose an autocommand which will give all the changes data after the confirmation prompt is confirmed. That should help me implement the functionality perfectly. Also this does not yet support copy and move functionalities which I will add them later.

local lsp_get_client = function(name, bufnr, all)
	local clients
	local buf = nil
	if name and bufnr then
		clients = vim.lsp.get_clients({
			bufnr = buf,
			name = name,
		})
	elseif name and not bufnr then
		clients = vim.lsp.get_clients({
			name = name,
		})
	elseif bufnr and not name then
		clients = vim.lsp.get_clients({
			bufnr = buf,
		})
	else
		clients = vim.lsp.get_clients()
	end
	if #clients == 0 then
		vim.notify("No " .. name .. " client found", vim.log.levels.WARN)
		return
	end
	if all then
		return clients
	end
	return clients[1]
end

vim.api.nvim_create_autocmd("User", {
	pattern = {
		"MiniFilesActionCreate",
		"MiniFilesActionDelete",
		"MiniFilesActionRename",
	},
	callback = function(args)
		local clients = lsp_get_client(nil, nil, true)
		local willMethod
		local didMethod
		local changes
		if clients and #clients > 0 then
			if args.data.to and not args.data.from then
				willMethod = "workspace/willCreateFiles"
				didMethod = "workspace/didCreateFiles"
				changes = {
					files = {
						uri = vim.uri_from_fname(args.data.to),
					},
				}
			elseif args.data.from and not args.data.to then
				willMethod = "workspace/willDeleteFiles"
				didMethod = "workspace/didDeleteFiles"
				changes = {
					files = {
						uri = vim.uri_from_fname(args.data.from),
					},
				}
			else
				willMethod = "workspace/willRenameFiles"
				didMethod = "workspace/didRenameFiles"
				changes = {
					files = {
						oldUri = vim.uri_from_fname(args.data.from),
						newUri = vim.uri_from_fname(args.data.to),
					},
				}
			end
			for _, client in ipairs(clients) do
				if client:supports_method(willMethod) then
					local resp = client:request_sync(willMethod, changes, 1000)
					if resp and resp.result then
						vim.lsp.util.apply_workspace_edit(resp.result, G.offset_encoding)
					end
				end
			end
			for _, client in ipairs(clients) do
				if client:supports_method(didMethod) then
					client:notify(didMethod, changes)
				end
			end
		end
	end,
})

[231tr0n]

Ok so I just figured out that the best way to do it would be via the MiniFiles.synchronize function.

Basically apply the willmethods in the if confirm_res == 1 then condition.
https://github.com/nvim-mini/mini.files/blob/2db6db37c37ee5955fe72907e33fa31cd2dd0fd4/lua/mini/files.lua#L839

They we apply the didmethods in the unexposed H.fs_actions_apply function after H.trigger_event('MiniFilesAction' .. action_titlecase, data)
https://github.com/nvim-mini/mini.files/blob/2db6db37c37ee5955fe72907e33fa31cd2dd0fd4/lua/mini/files.lua#L2689C7-L2689C67

If you are ok with supporting lsp file actions natively in mini.files, Can I raise a PR to do so?

[echasnovski]

Thanks for sharing! This is originally discussed in #400 and another PR in #1586.

The issue I am facing here is that before calling didmethods, willmethods should be called and that too before the changes are made, and I needed a way to get the changes done by mini.files before they are done and once they are confirmed. I just tried looking at the autocommands and non of them seem to help. So Is there any way to expose an autocommand which will give all the changes data after the confirmation prompt is confirmed. That should help me implement the functionality perfectly.

It was discussed in #1586. General idea is that it is still planned to be built into 'mini.files', but the priority is low-ish at the moment.

If you are ok with supporting lsp file actions natively in mini.files, Can I raise a PR to do so?

The main concern here is described here. The problem is that 'mini.files' can not reasonably guarantee that the actions will actually happen. Thus there needs to be a research about the case "willXxx event is triggered but the action is not performed; how to pass this info to the server?".

It is the main blocker here as this requires dealing with several LSP servers while the coverage of how they implement these methods is limited.

The best way for you to help is to share which LSP server(s) did you use to test this code and maybe try to investigate the described problem with them. The 'mini.files' code itself I'd rather do myself.

[231tr0n]

The main concern here is described #1586 (comment). The problem is that 'mini.files' can not reasonably guarantee that the actions will actually happen. Thus there needs to be a research about the case "willXxx event is triggered but the action is not performed; how to pass this info to the server?".

I dont think this part is possible atleast according to what I read from lsp spec. The only solution I see here would be to verify if that action will succeed and apply the willMethods for the actions which will be successful.

As for which lsp to use, I would suggest gopls for golang. It supports all the methods.
https://github.com/golang/tools/blob/master/gopls/internal/protocol/generate/tables.go#L262

[231tr0n]

copy - this will only fail if the directory does not exist or if there is another file with the same name.
rename - it will fail if there is another file with the new name.
delete - should pass without any issues as long as the file exists.
create - should check if the file already exists as that is the only case in which this fails.
move - should check if the destination file and directory already exists or not.

One more thing would be to look out for whether the user has write permissions in the destination folder and write permissions on the files being operated in all the cases.

Probably making sure these conditions are right and then triggering the willMethods should do the job.
This is what I would do.

[echasnovski]

I dont think this part is possible atleast according to what I read from lsp spec. The only solution I see here would be to verify if that action will succeed and apply the willMethods for the actions which will be successful.

I am afraid that this is true, but it is not 100% possible with 'mini.files' because there are a lot weird edge cases of how file manipulation is possible.

copy - this will only fail if the directory does not exist or if there is another file with the same name. rename - it will fail if there is another file with the new name. delete - should pass without any issues as long as the file exists. create - should check if the file already exists as that is the only case in which this fails. move - should check if the destination file and directory already exists or not.

One more thing would be to look out for whether the user has write permissions in the destination folder and write permissions on the files being operated in all the cases.

Probably making sure these conditions are right and then triggering the willMethods should do the job. This is what I would do.

I am aware of these conditions, thanks. The problem is that verifying them is not as straightforward as one would hope because a batch of possibly conflicting file system actions can be processed at once. So this either requires a lot of dedicated code to do properly or will fail uncontrollably when the action fails. Researching how different popular LSP servers behave in the latter situation and design around it is what's halting this change. It will get there eventually, just not now-ish.

As for which lsp to use, I would suggest gopls for golang. It supports all the methods.
https://github.com/golang/tools/blob/master/gopls/internal/protocol/generate/tables.go#L262

Unfortunately, this is not the case. It only supports didCreateFiles, as other methods are not implemented.

[231tr0n]

I dont think this part is possible atleast according to what I read from lsp spec. The only solution I see here would be to verify if that action will succeed and apply the willMethods for the actions which will be successful.

I am afraid that this is true, but it is not 100% possible with 'mini.files' because there are a lot weird edge cases of how file manipulation is possible.

copy - this will only fail if the directory does not exist or if there is another file with the same name. rename - it will fail if there is another file with the new name. delete - should pass without any issues as long as the file exists. create - should check if the file already exists as that is the only case in which this fails. move - should check if the destination file and directory already exists or not.

One more thing would be to look out for whether the user has write permissions in the destination folder and write permissions on the files being operated in all the cases.

Probably making sure these conditions are right and then triggering the willMethods should do the job. This is what I would do.

I am aware of these conditions, thanks. The problem is that verifying them is not as straightforward as one would hope because a batch of possibly conflicting file system actions can be processed at once. So this either requires a lot of dedicated code to do properly or will fail uncontrollably when the action fails. Researching how different popular LSP servers behave in the latter situation and design around it is what's halting this change. It will get there eventually, just not now-ish.

As for which lsp to use, I would suggest gopls for golang. It supports all the methods.
https://github.com/golang/tools/blob/master/gopls/internal/protocol/generate/tables.go#L262

Unfortunately, this is not the case. It only supports didCreateFiles, as other methods are not implemented.

Lol I thought it was implemented. After going through the source only to find it replies not implemented XD.