Suggested mapping overrides help's K

[gegoune]

In help files K can be used to jump to topic under the cursor. Suggested mapping overrides it. Neovim hover handler (vim.lsp.buf.hover) which I think many users have also mapped to K through on_attach function will not have that issue as it will not be mapped for help files. It makes sense to create global mapping for hover.nvim as it's useful beyond files with LSP attached. I have came up with following guard, not sure if it's the right way of doing it, but perhaps you can think of better way and update readme accordingly?

vim.keymap.set('n', 'K', function()
  if vim.bo.filetype ~= 'help' then
    require('hover').hover()
  end

  vim.api.nvim_feedkeys('K', 'ni', true)
end)

[lewis6991]

I didn't know about the behaviour of K in help files. I've always used <C-]> which does the same thing.

[gegoune]

Or, even more importantly, it overrides K mapping which by default is used for invoking keywordprg. I am thinking, would keywordprg provider make sense?

[lewis6991]

That was my first thought with this plugin, however, keywordprg is very limited in what it can do. It must be a shell command which gets invoked.

We can add keywordprg as a provider to this plugin that runs keywordprg and displays the output in a floating window.

[gegoune]

I think common use case, other than shelling out, is to use :help.

[gegoune]

Related neovim/neovim#18997

[WillEhrendreich]

I'm trying to figure out how to add keywordprg as a provider, and I'm just not sure how to do it. It's something like having the :term// output captured and then.. displaying it.. but.. trying to call it through require("hover.async.job").job({"help", wordvariable}) gives back nil. same with when i use ":help" as the input.I'm on windows, and as such, Man fails and freezes for 30sec, so I'm trying to avoid that. the whole reason that I want this is that the keywordprg for me switches to a whole new tab, and I'm really uninterested in having that, I want it in the hover docs.