(re-)allow hovers from language servers of other buffers

[jmbuhr]

Describe the bug

I wrote a plugin to enable language features for code embedded in other documents (e.g. markdown code blocks) by maintaining hidden buffers with only the language content and relaying language server requests to those hidden buffers. This enables things like autocompletion, go to definition and hover documentation.

But hover documentation will be broken by cfdf5e6 because it explicitly disables hovers that come from buffers other than the current one.

Steps to reproduce

See quarto-dev/quarto-nvim#32

Expected behavior

Hovers from other buffers can still be shown. Some form of opt-in or opt-out via a flag is necessary to serve both usecases.

Neovim version (nvim -v)

v0.9.0-dev-974+g631775c05d

Vim (not Nvim) behaves the same?

no

Operating system/version

linux

Terminal name/version

kitty

$TERM environment variable

xterm-256color

Installation

apt

[glepnir]

use api.nvim_buf_call can allow you run the function in a target buffer.

[jmbuhr]

This does allow me to open up the hover, but the hover won't close again (due to being executed in another buffer) and it breaks the other lsp requests I am handling like go to defintion.

The cleanest solution would be a different solution to cfdf5e6 , as this makes hovers handle differently from other lsp requests and introduces arbitrary constraints. I will try to come up with something as well. In its current form I think this is a regression.

[glepnir]

also why you don't try rewrite the default handler in your local ?

vim.lsp.handler['textDocument/hover'] = function(_, result)
  --your logic.
end

or send the request by yourself by using lsp.buf_request lsp.buf_request_all

[jmbuhr]

Thanks for the suggestion! But won't this break or not work for users that configured their handlers e.g. to use a certain type of border for hover windows?

I think the default handler shouldn't make an assumption about the buffer, since all the other handlers don't do so either (this is handled by the request and response content). The commit I linked that introduces this assumption also mentions that it is a workaround for which we would eventually need a better solution. So I would prefer to not release it in in its current form to not break uses of the api. Otherwise I'll end up with a workaround around a workaround in my plugin.

[glepnir]

like i said you can use lsp.buf_request or lsp.buf_request_all to do it in your plugin. it not break any handlers.

 vim.lsp.buf_request(buffernumber, 'textDocument/hover', params, function(_, result, ctx)
         -- your logic
 end)

examplay what i do in lspsaga https://github.com/glepnir/lspsaga.nvim/blob/main/lua/lspsaga/hover.lua

[jmbuhr]

Thanks you for your helpful comments! I am indeed already using that and have now added my own handler to handle hovers (just a copy and past of the nvim one without the buffer check) here: jmbuhr/otter.nvim@f29a9f3. This works, but can be improved.

By handling the hover in the plugin I am loosing user configuration done with vim.lsp.with, e.g. a user may have something like this in their config:

    vim.lsp.handlers["textDocument/hover"] = vim.lsp.with(vim.lsp.handlers.hover,
      { border = ....... })

I tried various debugging functions to get the config out of the overwritten handler function, but was unable to to so.
Do you know if this is possible? Thanks for all your help!

[justinmk]

I tried various debugging functions to get the config out of the overwritten handler function, but was unable to to so.

With #22598 you could sniff the config via:

vim.on_fun(vim.lsp.handlers, 'textDocument/hover', function(...)
  return function(err, result, ctx, config)
    -- `config` passed here is the user-specified config.
  end, ...
end)

this is kinda hacky though.