Vim icon indicating copy to clipboard operation
Vim copied to clipboard

No scroll after show hover (`gh`)

Open thekswenson opened this issue 6 years ago • 22 comments

Describe the bug Press 'gh' when the cursor is on a function call. There is no way to see the content of a docstring when it doesn't fit in the hover box that appears. That is, scrolling in the hover box is impossible.

Contrast this to when you hover with the mouse. In this case you can use the scroll wheel to inspect the entire docstring.

This seems to be related to the comment by @unode in https://github.com/VSCodeVim/Vim/issues/1703#issuecomment-461607742 .

To Reproduce Steps to reproduce the behavior:

  1. Go to a function call that has a substantial docstring.
  2. type 'gh'
  3. see that you cannot view the entire docstring and cannot scroll
  4. move the mouse to the hover box and see that it disappears

Expected behavior I expect to have a key (or combination) that will scroll the hover box. The combination 'gh' is rather useless without this functionality.

Screenshots

Screenshot from 2019-05-08 11-29-08

Environment (please complete the following information):

  • Extension (VsCodeVim) version: v1.7.1
  • VSCode version: 1.33.1
  • OS: Linux (Ubuntu)

Additional context Add any other context about the problem here.

thekswenson avatar May 08 '19 14:05 thekswenson

AFAIK, this is not possible in VSCode's current API. Give https://github.com/microsoft/vscode/issues/69836 an upvote.

J-Fields avatar Aug 04 '19 22:08 J-Fields

Is there any progress on this?

DemoorBug avatar Sep 01 '21 07:09 DemoorBug

Is there any progress on this or is there any way I can help?

Ygshvr avatar May 18 '22 14:05 Ygshvr

Is there any progress on this or is there any way I can help?

It's a pretty old issue originated from VSCode itself. Please upvote and subscribe https://github.com/microsoft/vscode/issues/69836. I don't think currently VSCodeVim could do anything for this problem.

YalandHong avatar Jan 05 '23 03:01 YalandHong

Yay! VSCode API is now ready for it!

ObstinateM avatar Mar 08 '23 18:03 ObstinateM

Now the fun question is "what keybind should trigger it?"

Since VSCodeVim overrides the CTRL keys, the default CTRL-K + CTRK-I won't be a solution

Maybe we could follow the design philosophy of the VSCode implementation just doing the same key combo twice and have it be gh to show the menu and then a second gh to focus it? (Potentially with the usual h,j,k,l and other basic navigation keys for scrolling?)

I want to take a crack at this but I'd like to make sure I'm properly following the general design philosophy here.

njrardin avatar Mar 11 '23 01:03 njrardin

Just another thought, maybe gh should just hover straight into the window and then esc can get you out of it?

njrardin avatar Mar 11 '23 01:03 njrardin

Just another thought, maybe gh should just hover straight into the window and then esc can get you out of it?

I like this idea, imo it would integrate well in the vim flow

ObstinateM avatar Mar 11 '23 21:03 ObstinateM

Now the new API is out of beta. I once thought scrolling will work out of the box, but now I'm a bit confused...

https://github.com/microsoft/vscode/issues/69836#issuecomment-1491306580

"vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["K"],
      "commands": ["editor.action.showHover"]
    },
]

Now that the description of the command has been changed to Show or Focus Hover, I'd expect hitting K twice will give me the ability to move up/down in the hover, however it seems to me that the hover is never focused...

rami3l avatar Apr 01 '23 02:04 rami3l

I was able to use gh to show and focus the hover in vscode version 1.77.0, by calling the editor.action.showHover command twice. I guess it needs to be called once to show the hover and then again to focus it.

settings.json

"vim.normalModeKeyBindingsNonRecursive": [
  {
    "before": ["g", "h"],
    "commands": ["editor.action.showHover","editor.action.showHover"]
  },
],

The only remaining problem is that by default you have to scroll in the hover using the arrow keys, home, end, page up, and page down. I was able to scroll in the hover using h, j, k, l by adding the key bindings below.

keybindings.json

[
  {
    "key": "h",
    "command": "editor.action.scrollLeftHover",
    "when": "editorHoverFocused"
  },
  {
    "key": "j",
    "command": "editor.action.scrollDownHover",
    "when": "editorHoverFocused"
  },
  {
    "key": "k",
    "command": "editor.action.scrollUpHover",
    "when": "editorHoverFocused"
  },
  {
    "key": "l",
    "command": "editor.action.scrollRightHover",
    "when": "editorHoverFocused"
  },
]

EdRW avatar Apr 05 '23 06:04 EdRW

@EdRW I have thought about the same hack but sadly it didn't work on my Mac. What platform are you on?

rami3l avatar Apr 05 '23 12:04 rami3l

@rami3l @EdRW Use editor.action.showDefinitionPreviewHover it pops up hover with focus.

"vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": [
        "g",
        "h"
      ],
      "commands": [
        "editor.action.showDefinitionPreviewHover"
      ]
    }
  ] 

igorstr avatar Apr 08 '23 14:04 igorstr

@igorstr Wow it finally works! Thanks a lot for the fix!

rami3l avatar Apr 09 '23 11:04 rami3l

Issue could be closed. New keyboard shortcuts for hovers were added in version 1.77 Link to update

igorstr avatar Apr 10 '23 12:04 igorstr

@igorstr May I know where you have found this editor.action.showDefinitionPreviewHover fix?

Personally I can't find anything in the changelog about it except the new CTRL-K + CTRK-I shortcut as mentioned by @njrardin...

rami3l avatar Apr 10 '23 13:04 rami3l

@rami3l Command available in command palette by keyword “hover”. Was added with older update 1.40

with recent update keyboard shortcuts for navigation were added to the hover widget. So now it’s possible to bind navigation in hover.

Anyway this issue has nothing to do with vscodeVim plugin, moreover I don’t think there is any issue anymore.

upd. showHover shows widget without focus(have no idea why) showDefinitionPreviewHover shows with focus

igorstr avatar Apr 10 '23 13:04 igorstr

@igorstr Thanks a lot for your detailed explanation!

It seems like this showHover is hardcoded in the plugin so it could be potentially changed for the better...

https://github.com/VSCodeVim/Vim/blob/3f5491cc0417e85e91b051f0ce2b743bca5241ed/src/actions/commands/actions.ts#L2485

rami3l avatar Apr 10 '23 15:04 rami3l

This feature works as expected using a regular vscode keybinding, so it's not an upstream issue. gh should work the same as editor.action.showHover, but it doesn't.

Upon first use, the editor should show the Hover window. Upon second consequent use, the editor should focus the aforementioned hover window.

Instead what happens is that we only get the first part. Every consequent usage re-triggers the first functionality.

Here's my working keybindings.json:

{
    {
        "key": "shift+k",
        "command": "editor.action.showHover",
        "when": "editorTextFocus && vim.mode == 'Normal'"
    },
        {
        "key": "ctrl+u",
        "command": "editor.action.pageUpHover",
        "when": "editorHoverFocused",
    },
    {
        "key": "ctrl+d",
        "command": "editor.action.pageDownHover",
        "when": "editorHoverFocused",
    }
}

This works as expected. It first opens an unfocused hover window (not requiring Escape to exit), then focuses it when needed, which allows me to scroll.

Bear in mind, im using K instead of gh. I'm sure it's possible to make it work with gh instead, but i haven't tried.

eilefsen avatar Jan 21 '24 16:01 eilefsen

Thanks for the comment @eilefsen . Do you have any hints for getting gh to work similarly? I'm not very familiar with how vscode works.

thekswenson avatar Jan 22 '24 15:01 thekswenson

Combining the posts of @eilefsen and @igorstr I get the expected behaviour.

  1. add to settings.json:
"vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["g", "h"],
      "commands": ["editor.action.showDefinitionPreviewHover"]
    }
  ] 
  1. add to keybindings.json:
[
  {
      "key": "ctrl+u",
      "command": "editor.action.pageUpHover",
      "when": "editorHoverFocused",
  },
  {
      "key": "ctrl+d",
      "command": "editor.action.pageDownHover",
      "when": "editorHoverFocused",
  },
  {
      "key": "k",
      "command": "editor.action.scrollUpHover",
      "when": "editorHoverFocused",
  },
  {
      "key": "j",
      "command": "editor.action.scrollDownHover",
      "when": "editorHoverFocused",
  }
]

I'm hesitant to close the issue, since I would expect this to work without any configuration.

thekswenson avatar Jan 22 '24 15:01 thekswenson

@thekswenson Thanks for the summary. I can finally work with the hover widget with natural vim bindings.

One thing to add. Personally I use ctrl+c instead of esc much more often. The following binding lets you escape the focus of the hover widget without closing it and brings you back to the text on the editor. One may argue that it should just as well close the widget, but I had hard time finding that command. The extension.vim_escape command is a temporary hack, but it's good enough for me.

In keybindings.json:

  {
    "key": "ctrl+c",
    "command": "extension.vim_escape",
    "when": "editorHoverFocused",
  }

IanLiuTW avatar Feb 04 '24 01:02 IanLiuTW

@eilefsen

Here's my working keybindings.json:

{
    {
        "key": "shift+k",
        "command": "editor.action.showHover",
        "when": "editorTextFocus && vim.mode == 'Normal'"
    },
        {
        "key": "ctrl+u",
        "command": "editor.action.pageUpHover",
        "when": "editorHoverFocused",
    },
    {
        "key": "ctrl+d",
        "command": "editor.action.pageDownHover",
        "when": "editorHoverFocused",
    }
}

This binding unfortunately shadows my [ "ctrl+w", "K" ] binding (it mimics Vim's window movement). Is there a way to check if there's an active chord in the when condition so that you can prevent collision?

EDIT: This is also shadows chords like fK 😕, really annoying. I wish that the editorHoverFocused can just be fixed on the plugin level instead of relying on hacks like this. showDefinitionPreviewHover is not really a good substitute because it unconditionally focuses the hover, forcing you to unfocus it every time.

musjj avatar Apr 25 '24 17:04 musjj