kludge up for Eglot's use of codeAction/resolve

[cmm]

This is obviously a hack but it works for my use case, which is the usual "need to use (based)Pyright & Ruff with Eglot".

Prior to this change, Ruff's code actions (at least visible ones, like organizing imports) did not work with Eglot because Eglot invokes such actions through codeAction/resolve only and since Ruff is normally not the promary LSP server its declaration of support for codeAction/resolve was not propagated by the proxy.

My main problem with all this is that I have no idea why codeAction/resolve even exists or what exactly it's supposed to do (and I am furthermore unable to understand the relevant part of the spec), so the approach here, while fixing my immediate problem, is most likely wrong in general.

And it probably would be inadequate in case of several proxied servers with resolve support.

But posting in case anyone finds this useful.

[techee]

Thanks, I've finally had some time to look into this.

You are right - servers requiring codeAction/resolve won't work correctly right now (even though I believe that servers should respect clients declaring missing codeAction/resolve support and fall back to simple textDocument/codeAction containing all the details).

My main problem with all this is that I have no idea why codeAction/resolve even exists or what exactly it's supposed to do (and I am furthermore unable to understand the relevant part of the spec)

The reason is this: by first calling textDocument/codeAction you typically populate some menu with actions that can be performed for the given position in the editor such as

Do stuff 1
Do stuff 2
Do stuff 3
Do stuff 4

At this point, you don't really need the source code modifications for all the items - just the action names that are shown in the menu. When the user clicks say Do stuff 3, you call codeAction/resolve for it which returns the actual modifications that should be performed in the editor.

Without textDocument/codeAction support, all the items in the menu have to contain the modifications at the time you call textDocument/codeAction - this can be expensive when there are many items in the menu (or when the actions are complicated) and unnecessary, because at the end the user selects just one of the items.

so the approach here, while fixing my immediate problem, is most likely wrong in general.

And it probably would be inadequate in case of several proxied servers with resolve support.

Right. The trouble with your approach (apart from some other minor things I noticed in your patch) is that it will only work with one server supporting codeAction/resolve, not when there are more of them. Ideally, the proxy should remember all the items returned by textDocument/codeAction from all the servers and then, when codeAction/resolve is called, dispatch it to the correct server that returned the given item. If you send it to all the servers, those that didn't send the particular item will return an error.

This is surely doable, I might have a look at it myself in the future.

[cmm]

to be honest this PR should be deservedly considered total abandonware, in fact I should have closed it right at the moment of adopting https://github.com/rassumfrassum but forgot. sorry!

The reason is this:

that definitely made some things click. thanks for taking the time, much appreciated!

[techee]

https://github.com/rassumfrassum

Out of curiosity, what is this? It points me to some user profile.

[cmm]

because I also can't type for some reason, here's the correct link: https://github.com/joaotavora/rassumfrassum

[techee]

Ah, nice, good to know there's an alternative.