I’ve been using lspconfig with cmp and other neovim core stuff almost for a year now. But there is one thing that is just missing from coc-nvim. Coc has ability to invoke list of all available code actions for buffer with action like fix all fixable issues or fix some error on line 2. Somehow there is no such ability in core lsp implementation. Why is that? I’ve read this Code Actions · neovim/nvim-lspconfig Wiki · GitHub . But how coc can implement this but neovim can’t?
Do you have a reference to the functionality you are looking for? I am only aware of coc.nvim/codeActions.ts at 6552b6a74ee666490cbf6db3c38c8e5bf5816283 · neoclide/coc.nvim · GitHub which applies all quickfixes recursively, and coc-tslint-plugin/fixAll.ts at 1716ba8c55b9adb21a61ae9065884459a6fe0f6a · neoclide/coc-tslint-plugin · GitHub but that is obtained from the server as a separate fix all action (and thus should be available with builtin lsp too).
I mean, what you can do is write a function that goes to each diagnostic and tries to call the preferred code action for each diagnostic element if applicable (this involves a ton of code action requests), but there is nothing in the lsp specification that allows you to fetch all available code actions for the buffer (I wish)
You could set the range to the entire buffer and send all diagnostics in the context. I do that in my config (more precisely, I check for code actions in the current position and if that doesn’t return anything I try again using the entire document) and it works fine with gopls, not sure if that strategy works with other servers though.
Servers can offer a source.fixAll action (see e.g. VS Code API | Visual Studio Code Extension API). This seems to be similar to what tslint seems to do, although they don’t filter based on the kind but the title.
Yea, this behavior is probably very server dependent.
I played around a bit with using location list for this, e.g.
:lua vim.diagnostics.setloclist()
:ldo lua vim.lsp.buf.code_action({apply=true, context={only={'quickfix'}}})
but unfortunately this doesn’t work since LSP requests are asynchronous and document synchronization complains after the first edit. I guess this would require a synchronous version of code_action?
The spec clearly defines that textDocument/codeAction can take a range. I’d be surprised if servers didn’t support listing the code actions for any given ranges. Most of the servers that I use don’t even support code actions though, so I can’t confirm.
To be clear I’m not applying code actions automatically, I’m just retrieving them and showing the UI for selection. If we were to apply them automatically, it would need to be similar to formatting a buffer with multiple servers, you gotta do them in order.