Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to intercept ["workspace/executeCommand"] to use a custom lua function instead of sending to LS? #858

Closed
lbiaggi opened this issue Apr 21, 2021 · 8 comments

Comments

@lbiaggi
Copy link
Contributor

lbiaggi commented Apr 21, 2021

Hi, I’m trying to contribute / use this ltex-ls with neovim built-in client, so far, this is what I could achive alone ltex.lua.

This LS has a nonstandard way to implement 3 actions at the client side with involves intercepting these commands from workspace/executeCommand

  1. add word to a custom dict (_ltex.addToDictionary)
  2. add ignore rule. (_ltex.disableRules)
  3. add false positive. (_ltex.hideFalsePositives)

These actions are generated by the default handler of code action, what I want is when they happen instead of trying to communicate with LS, execute my custom function.

Regarding coding in lua / neovim lsp client config, what I can improve, there is a better solution for anything already done?

Regards,
Lucas

@mjlbach
Copy link
Contributor

mjlbach commented Apr 22, 2021

I don't really understand what you're asking. These questions generally belong on discourse, but I'll try to ask some clarifying questions here.

What do you mean "intercepting a command"? We send the request for executeCommand here and process the handler here

You can override either of these.

Regarding coding in lua / neovim lsp client config, what I can improve, there is a better solution for anything already done?

This is a broad question? Are you asking with regards to your snippet or the language client in general?

I would just file the work you have as a PR and it can be discussed there.

@lbiaggi
Copy link
Contributor Author

lbiaggi commented Apr 22, 2021

Default handler give this code action menu

nvim.mp4

if I accept any of the first three, the debug log will be similar to these lines

[ DEBUG ] 2021-04-22T06:47:49-0300 ] /usr/share/nvim/runtime/lua/vim/lsp.lua:887 ]	"LSP[ltex]"	"client.request"	1	"workspace/executeCommand"	{  arguments = { {      uri = "file:///home/lbiaggi/hd/projects/papers/defesa-final/teste.tex",      words = {        ["pt-BR"] = { "Tist" }      }    } },  command = "_ltex.addToDictionary",  title = "Add 'Tist' to dictionary"}	<function 1>	1
[ DEBUG ] 2021-04-22T06:47:49-0300 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:390 ]	"rpc.send.payload"	{  id = 15,  jsonrpc = "2.0",  method = "workspace/executeCommand",  params = {    arguments = { {        uri = "file:///home/lbiaggi/hd/projects/papers/defesa-final/teste.tex",        words = {          ["pt-BR"] = { "Tist" }        }      } },    command = "_ltex.addToDictionary",    title = "Add 'Tist' to dictionary"  }}
[ DEBUG ] 2021-04-22T06:47:49-0300 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:491 ]	"decoded"	{  id = 15,  jsonrpc = "2.0",  result = {    errorMessage = "Unknown command '_ltex.addToDictionary', ignoring",    success = false  }}
[ DEBUG ] 2021-04-22T06:47:49-0300 ] /usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:442 ]	"default_handler"	"workspace/executeCommand"	{  bufnr = 1,  client_id = 1,  params = {    errorMessage = "Unknown command '_ltex.addToDictionary', ignoring",    success = false  }}

unfortunately, these commands aren't server side they are supposed to be a wrapper around a local function which will execute the expected action

What I meant by intercepting was, do something different if command == _ltex.addToDictionary doesn't send RPC call, use this local function instead. I just want to override these 3 specific cases and let the others work as they were

This is a broad question? Are you asking with regards to your snippet or the language client in general?
I would just file the work you have as a PR and it can be discussed there.

Ok, my bad since, it is the first time I use lua to something, and I'm not that comfortable, will do it later.

@mfussenegger
Copy link
Member

mfussenegger commented Apr 22, 2021

I think this relates to neovim/neovim#14115

Intercepting the handler for workspace/executeCommand would be too late, because that's called once the server responds with a result for a executed command.

You'd have to override the function used to send commands to the handler or override the code actions

@mjlbach
Copy link
Contributor

mjlbach commented Apr 22, 2021

You'd have to override the function used to send commands to the [server]

This is what I would recommend doing in the case of this client

@lbiaggi
Copy link
Contributor Author

lbiaggi commented Apr 22, 2021

This is what I would recommend doing in the case of this client

Can you detail what do you mean? I did not understand

@mfussenegger
Copy link
Member

This is what I would recommend doing in the case of this client

Can you detail what do you mean? I did not understand

I think you should be able to do something like this:

local orig_execute_command = vim.lsp.buf.execute_command
vim.lsp.buf.execute_command = function(command)
  if command.command == '_ltex.addToDictionary' then
    -- ...
  else
    orig_execute_command(command)
  end
end

vim.lsp.buf.execute_command is called once the user selects the option from the code-actions.

@lbiaggi
Copy link
Contributor Author

lbiaggi commented Apr 22, 2021

I think you should be able to do something like this:

local orig_execute_command = vim.lsp.buf.execute_command
vim.lsp.buf.execute_command = function(command)
  if command.command == '_ltex.addToDictionary' then
    -- ...
  else
    orig_execute_command(command)
  end
end

vim.lsp.buf.execute_command is called once the user selects the option from the code-actions.

Hmm ok, I got it. If I have two LSP connected (e.g. texlab and ltex-ls complete each other functionalities) this would cause any problem?

@mjlbach
Copy link
Contributor

mjlbach commented Apr 25, 2021

Closing in favor of continued discussion in #863

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants