Feature Request - more special server commands

[weilbith]

Hey 👋

Here the author of #56. You solved the requested feature pretty fast and nicely by adding the register_method. And I wonder if this feature could be extended. But it doesn't seem too obvious how to extend, so I would like to discuss the solution approach first before thinking about writing a PR.

So I have more LSP server specific commands which are somewhat location related (or could be interpreted like this). So for example the rust-analyzer allows to show a list of tests that are using/related to the piece of code under the cursor. It additionally provides information how to run each individual test etc. pp. Which means it is unfortunately not a simple response with Location[]. Though the request parameter are still just TextDocumentPositionParams.
In this exact case, the response structure of the rust-analyzer looks something like this:

{
  result = {
    {
      runnable = {
        args = { --[[ ... ]] },
        kind = "...",
        label = "...",
        location = { --[[ ... ]] },
      }
    },
    {
      runnable = {
        args = { --[[ ... ]] },
        kind = "...",
        label = "...",
        location = { --[[ ... ]] },
      }
    },
  }
}

So if you take this response and map each entry it to the nested location attribute of it, this would be a regular LSP Location[] data structure again.

Taking this example, I thought about a generic solution approach that puts as less burden as possible on the plugin. And my proposal would be to extend your method representation by adding an optional property called response_preprocessor_callback or something similar (just trying to be expressive). The idea would then be that after the server has responded, the respective logic checks if such a callback is defined and if so, calls it and takes the output of that function to continue processing as always. That would mean for any existing method and all already in use custom ones, nothing changes at all. So it is fully backwards compatible. It also should require not many locations of code to touch and remain hopefully a quite minimal addition.

So an example configuration of a user like me would look the following:

require('glance').register_method(
  name = 'rust-analyzer-related-tests',
  label = 'Related Tests',
  method = 'rust-analyzer/relatedTests',
  response_preprocessor_callback = function(response)
    return vim.tbl_map(function(entry)
        return entry.runnable.location
    end, response.result or {})
  end
)

What do you think?

[DNLHC]

Hey, sorry for not responding sooner I've been busy lately

You can try to do the preprocessing you need with the before_open hook.

  hooks = {
    before_open = function(results, open, jump, method)
      if method == 'rust-analyzer-related-tests' then
        open(vim.tbl_map(function(entry)
          return entry.runnable.location
        end, results))
      else
        open(results)
      end
    end,
  }

Does this work for you?

[weilbith]

No worries maintaining plugins is a horror. I have no expectations. 🙂

Nice! That works! Sorry, haven't thought about this. 🙈
Thank you very much! 🙏🏾