Please provide an API to trigger a hover-like tooltip.
Use case:
In my language extension, I want to let users know the type of the expression by pressing a combination of keys. This is similar to what hover does but:
Being able to show custom tooltips is also useful in different scenarios for providing extra information about the code.
@alexandrudima Do we already have an internal command that shows the hover?
editor.action.showHover will show the hover at the current editor position.
@alexandrudima, there are multiple issues with assigning a shortcut to editor.action.showHover:
If the hover is shown using the shortcut, IMO it should not block anything, and it should be displayed for as long as it is valid, i.e. the cursor is on the same symbol. And it should still be possible to dismiss it with Esc or the same shortcut (basically making it a toggle).
There are two ways for how to handle the moment keyboard input moves the cursor beyond the symbol that the hover is describing:
Personally I'd prefer the latter, but having a pref would be even better.
I totally agree with @monk-time and the suggested solution (keep showing) fits my use case perfectly.
also, it's currently impossible to show the alt hover with keyboard... need a solution for that.
(when you hold alt while hovering it shows different information).
here's the unsolved stackoverflow you find when googling for how to do this https://stackoverflow.com/questions/37654532/trigger-advanced-hover-information-with-keyboard
I ran into this issue today.
I use vim mode, so would like to see hover details using the keyboard. There's editor.action.showHover (cmd+K + cmd+I) (or vim's gh), but as mentioned by @monk-time the drawbacks are:
esc, which isn't very ergonomic.It _seems_ like these issues should be relatively easily solvable, because when I hover my mouse over an expression, instead of using the shortcut, the hover _does not_ move the focus away from the text editor, and it's automatically dismissed as soon as I continue typing.
So basically, an improvement would already be to have the shortcut implementation behave the same as the mouse-hover implementation (except for the delay, of course).
The main problem I have is that while there's an overridable keyboard shortcut for "show hover," there isn't a corresponding "hide hover." I have Ctrl+[ mapped to Esc functionality pretty much everywhere, but I'm not able to dismiss a hover without pressing Esc.
I'd also be okay with what @JeanMertz mentioned, and having the hover automatically disappear whenever typing or other actions are detected.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding
:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
It looks like many issues with the editor.action.showHover command have been resolved -- it seems to show up immediately, and it doesn't steal focus. It also get dismissed on almost any keystroke. Can this be closed or is there outstanding issues that still need to be addressed?
Most helpful comment
I ran into this issue today.
I use vim mode, so would like to see hover details using the keyboard. There's
editor.action.showHover(cmd+K+cmd+I) (or vim'sgh), but as mentioned by @monk-time the drawbacks are:esc, which isn't very ergonomic.It _seems_ like these issues should be relatively easily solvable, because when I hover my mouse over an expression, instead of using the shortcut, the hover _does not_ move the focus away from the text editor, and it's automatically dismissed as soon as I continue typing.
So basically, an improvement would already be to have the shortcut implementation behave the same as the mouse-hover implementation (except for the delay, of course).