On Wed, Jun 19, 2024 at 6:26 PM João Távora wrote: > > Troy, you seem to be on to something. It would seem Command shouldn't > be there in the dcase matcher in eglot-execute at all. Instead > ExecuteCommandParams should be there. > I suspected that might be the case (that Command was really supposed to be ExecuteCommandParams), but I hadn't exhaustively looked at everything, however you have now confirmed that suspicion. > > I may just have been thrown off by the confusing naming (naively > thinking that executeCommand executes Commands, but it doesnt). > Yes, that makes sense, I was confused for a bit as well until I had investigated why it had the "title" parameter, looked at the LSP specification and realized that it was meant for something else. > The reason no one has complained is probably that there aren't > many users invoking custom commands, and if there are, they could > be just using `jsonrpc-request` directly or using the deprecated > interface. Yes, that makes sense, I'd imagine people who are using custom commands are using the older eglot-execute-command interface since it's still functional. I had looked at it and saw that it was now deprecated so I attempted to use the new interface. > If so, patches welcome, as you > seem to have grasped how this code is supposed to work. > I've attached a patch which I believe addresses the issue. I did have to reorder the interfaces to put CodeAction before ExecuteCommandParams as both contain "command" parameters. Since eglot-strict-mode doesn't normally contain disallow-non-standard-keys, it causes eglot--dcase to match ExecuteCommandParams for a CodeAction interface if the optional "command" parameter is present. Reordering the interfaces allows them to match correctly since CodeAction contains a required "title" parameter which is not present in the ExecuteCommandParams interface.