aznhe21 / actions-preview.nvim

Fully customizable previewer for LSP code actions.
GNU General Public License v3.0
365 stars 9 forks source link

feat: Shim vim.ui.select to reuse as much of the code_action code #48

Open IndianBoy42 opened 2 months ago

IndianBoy42 commented 2 months ago

In-progress PR because I noticed that a large part of this repo is a copy of vim.lsp.buf.code_action, which has changed since it was copied into this repository. To make it less possible for it to get out of date we can just call vim.lsp.buf.code_action directly and use a shim that intercepts vim.ui.select to use the actions-preview backend only if kind == "codeaction".

I chose to add the shim the first time actions-preview is called, otherwise (say if it was wrapped in setup) if actions-preview is loaded before something else replaces vim.ui.select then we lose the shim. There may be some edge-cases around this wrapping that needs to be considered.

TODO:

IndianBoy42 commented 2 months ago

Please help testing, I haven't found any problems with rust-analyzer using it for a few days, if you use another LSP then it would be good to check if it does something different.

aznhe21 commented 1 month ago

Great job! Since breaking changes are acceptable, it would be good to make require(“actions-preview”).setup() mandatory. It would also be good to make require(“actions-preview”).code_actions() a function that only issues warnings as backward compatibility.

I will test this for a several days.

aznhe21 commented 1 month ago

Ah, but with this change, we can't enforce the use of actions-preview.nvim, can we? It might cause issues when used alongside dressing.nvim, etc. It would be great if there's a solution for this.

IndianBoy42 commented 1 month ago

So currently the way it works is that you still have to call actions-preview.code_action and there I override vim.ui.select with our handler. Our handler passes invocations with the wrong kind argument to the original handler. So our handler works if its installed after other plugins that override the vim.ui.select. If i only installed the handler in setup then I think other plugins might override (probably without passthrough), so AFAICT we have to have actions-preview.code_action().

I wish there was a more fundamental direct way to do this kind of "override for only a specific kind" thing. There was some discussion in github issues about a provider based method but I don't know if its backwards compatible so it might not happen. Currently I check if vim.ui.select is assigned to our function and don't reoverride. But if another plugin tried to do what we did then we'd keep stacking handlers on top of each other.