Open rhyek opened 7 years ago
This has to be a feature ordered directly by the Powers That Be, otherwise this level of silliness is hard to explain. How difficult is this to fix? If you can't move it, make it transparent!
I love you VS Code, but this is a total UX bug, and my boyfriend probably gets mad at me 800x per day every time that tooltip pops up, because I recommended he try VS Code. We're all programmers here, most of us have built our share of tooltips — so we know it's not impossible to move that thing somewhere else.
So then it seems there must be some kind of moral or philosophical objection to it at this point? Is it supposed to help us cultivate mindfulness, being aware of the context of our code at all times?
Just tried vscode and was loving it until this issue began to frustrate me. Seeing this simple issue ignored after so long has really killed my enthusiasm for the product.
Just in case though, the suggestion of moving it up by one line wouldn't be good enough for me. I often need to see quite a few lines above.
Aligning it to the right of the screen, putting in a seperate pane or even just letting me drag it to a place I like would all suit me fine.
As a work around you can disable parameter hints in settings.json
"editor.parameterHints.enabled": false
You can then press Ctrl+Shift+Space to make them popup when you need them.
This sucks, but one workaround is add
"editor.parameterHints": false,
to settings.json
, and use the editor.action.triggerParameterHints
shortcut key when you need parameter hints. ctrl+shift+space
by default
In Visual Studio, hold Ctrl for a while, the tooltip will dim down to let me see through it.
I think it's better than changing the position via a config.
@yume-chan can you still dim it with control? Not working for me.
There is a similar issue #30797 Here is its last message: "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."
There are 25 days left at the moment. Let's upvote! Note: upvote the original comment, not the vscodebot comment
This is important, get voting! Putting it below the cursor is better than nothing!
@nwg
can you still dim it with control? Not working for me.
I mean Visual Studio, not Code. I'm not using Visual Studio recently so I'm not sure if it's still in.
After reading the whole thread, I still don't understand why it is a challenge to place to pop-up below the cursor as most editors do and I would appreciate any additional insights into it. Maybe someone could just roughly describe the steps to accomplish this? However, if it is really an unsolvable problem, then I would like to point out this suggestion, which is also fine for me: https://github.com/Microsoft/vscode/issues/33752#issuecomment-425626433.
My current workaround is disabling the popup and triggering it manually, as https://github.com/Microsoft/vscode/issues/33752#issuecomment-568530834 describes. Another dirty solution is to make the popup transparent, similar to https://github.com/Microsoft/vscode/issues/22439 but I don't like this approach either.
A configuration option would be the way to go:
I'd love it if these were always visible in the upper right-hand corner, for instance.
For now, though, I do what philn16 said: Set editor.parameterHints.enabled
to false
and use Ctrl+Shift+Space (or whatever you have editor.action.triggerParameterHints
configured to) when you want the hints. Verbose version:
parameterhints
editor.action.triggerParameterHints
configured to) when you want the hints.It's a huge bummer to have to disable such a cool feature simply because there's no way to configure the position of the popup. Sigh. Oh well. Moving on...
Strange that this is still an issue when all other popup style info boxes can have their transparency changed. Why hasn't the parameterhints box been given this change also? Seems like a lack of consistency doesn't it?
September 3rd is this bug's 3rd birthday, I plan on making a cake for it. I will only be providing the ingredients though, you will have to compile it yourself. It's 3 now, but it won't be long before it's off to school, then college...where do the years go?...
This seems like a pretty annoying papercut. It's part of why we addressed the nuisance of ,
triggering signature help in object literals in https://github.com/Microsoft/vscode/issues/51731.
That said, there's a few things I could imagine:
Enter
is hit, signature help moves from the top to the bottom. This ensures you can glance back at whatever you already wrote.A bar/panel at the bottom of the editor that would appear with no delay could do the trick too.
But with the new flexible layout released in may 2020, a parameter info view that one can move everywhere would be nice too. Maybe a new activity being oriented towards code documentation that would implements the current parameter info tooltip as well as other documentation aggregator like DevDocs would be nice and complete.
I have a workaround to have access to this info tooltip without being annoyed by them. I explain it here #102198 because this highlighted another bug.
Here are other related issues more or less duplicate : #51253, #16221 (an awesome feature suggestion), #15667, #30797, #63144.
Happy 3rd birthday 33752 ! How the time flies, before we know it, you'll be off to college...having your own little bugs...
Just to confirm, based off https://github.com/microsoft/vscode/issues/33752#issuecomment-331409645, I can assume most people who want this setting would be ok with the parameterHints
widget being covered by the Intellisense
widget temporarily, like in the recording below:
Boggles my mind that an option for positioning is still not available. Call me weird, but I find it so annoying, I'm going back to JetBrains products. Seems VS Code devs are being incredibly stubborn around this...despite regularly providing tons of great updates otherwise. Oh well.
+1
My joke comment above was marked as spam. I've uinstalled VScode and intstalled Jetbrains Rider, it has this feature already. You can make a free buggy IDE or you can make a non-free IDE that is fit-for-purpose, it seems. Still subscribing to this bug, because I want to see how it ends and when it ends.
Please let us configure this pop up. It is so distracting!
A monstrosity like the one in my screenshot below is going to be super annoying and distracting no matter where in the editor you render it. In these cases, where the contents are this illegibly formatted and even truncated, I'd rather have this tooltip dynamically not show at all.
I feel like occurrences of this have steadily grown alongside the popularity of string literal union type guards for function params. In my screenshot this was spawned by a very simple but strictly typed object value accessor for a CSS in JS library.
Posting here to add my support for this issue. This pop-up often blocks my code and it's not configurable at all. It would be awesome to see some configuration options added to this pop-up or a key to press to make the pop-up translucent. Thank you!
Any news or updates on this issue? This is still an actual problem that often reminds about itself :( Snx!
I can't believe with all the frustration this has created for developers that this issue has not been addressed. It is literally the only thing keeping me from switching FT to vscode.
I really hate this feature. I'm wasting precious study time trying to configure settings.json to disable it- but nothing I've tried works. This box pops up and $@#-blocks me. It's distracting and obstructive. Please fix this. I cant wait till I graduate in 4 months.. the only reason I'm putting up with this bs is so I can follow along seamlessly with my guides which use VSC.
It is a strange thing when people can't appreciate how irksome a misfeature is, or even that it is a misfeature. Take Adobe's Brackets editor. Tried it, and immediately and amazingly found it couldn't do bracket-bouncing (aka toggling aka matching). And their reaction to complaints was much like "Really? Gee, I suppose we could do that in a future version..." Brackets couldn't do brackets, and they couldn't see a problem beforehand?
Obscuring code as you're writing is not a feature. Every JS tooltip/popup package I've seen allows positioning variations as needed so as not to obscure. Why did they go to that effort?
Also posting to voice my support with this issue, it is really anoying. I've gone down the route of disabling it and bringing it up when needed but I would like the option of changing the window's default position to be below like it is in Visual Studio and then have Intellisense below that (if both of them are open at the same time).
Voicing my support for this.
This happened to me while I was typing and need to see what code was above my current line.
Oops!
My company, Exodus / @exodusmovement is willing to put a 1 BTC bounty down for an intellisense placement configuration option ("above" as it is now, or "below" as it should be). At the time of this writing, 1 BTC is approximately $19,000 USD.
If we do this, this bounty campaign would need to expire by December 29th 23:59 UTC.
I don't write code anymore - but this Github issue is still one that I subscribe to and I'm surprised that 3 years later it's still not fixed. So we're effectively paying this bounty to spare my inbox 😄
Suggestions on how we should go about this bounty campaign? Ideally we transfer the 1 BTC to a steward on the VS Code team, and they decide who and how.
At minimum, I'd like some acknowledgement from the VS Code team that they'd be open to accept a PR for this fix should the PR meet their standards.
@jprichardson I'm not going to lie, that comment motivated me to look into this issue again haha. I rebased all my changes onto master
, and the branch can be found here. If you could test it out and let me know what you think, that would be great.
Or if you're unable to test, here's a little recording, feedback is much appreciated:
Specifically, I just want to reiterate my previous comment that the intellisense would cover this up. I didn't get any verbal feedback on that, so I want to confirm, is that alright? It was an issue brought up earlier by a maintainer, so I'm not sure if they'd reject any PR I make on those grounds.
@SneakyFish5
Your change looks like a big step the right direction!
Specifically, I just want to reiterate my previous comment that the intellisense would cover this up. I didn't get any verbal feedback on that, so I want to confirm, is that alright? It was an issue brought up earlier by a maintainer, so I'm not sure if they'd reject any PR I make on those grounds.
I don't see that as an issue. First off, it's an option, so if that bothers people they can keep using it the way it is now. Secondly, even doing that it's a huge improvement on what's there now!!
My observation is intellisense prioritizes over parameter hints in the stack, so I certainly hope they accept your PR. Great work!
Would it be possible to have a third option to have parameter hints below and then intellisense below (or to the right of) those?
Nice work @SneakyFish5!
Now we just need someone from the VS Code team to confirm their acceptance of such a change and we could get this wrapped up before our deadline of December 29th 23:59 UTC.
Although I think it's great that this issue is gaining some traction, the proposed solution suffers from a similar problem to the one this entire issue is about: previous relevant contextual information is being blocked from view by new information.
I'd rather we not go for the most immediate (but incomplete) solution for the sake of closing out the issue, personally. If people are bothered by the updates to the thread they can always unsubscribe.
@rhyek - I agree that @SneakyFish5's solution shouldn't close the issue. It is a good first step, and I'd vastly prefer the code below rather than above be blocked (the option their solution enables). But it shouldn't close the issue. Other choices for that option should be available in future, including showing the information in a panel that can be docked elsewhere (for instance, under the file list).
So for me next steps are:
Now, people will say "but if we take this solution nothing further will be done" and that's a danger; people need to keep advocating (at least, the ones for whom this isn't good enough). The counter to that, though, is "perfect is the enemy of good." Three years later, not taking a first step because we want the all-singing, all-dancing solution seems counter-productive. Incrementalism FTW! (I know, it's nearly 2021, "FTW" is so over now. But... ;-) )
Although I think it's great that this issue is gaining some traction, the proposed solution suffers from a similar problem to the one this entire issue is about: previous relevant contextual information is being blocked from view by new information.
I'd rather we not go for the most immediate (but incomplete) solution for the sake of closing out the issue, personally. If people are bothered by the updates to the thread they can always unsubscribe.
I agree this would be preferable, however when I looked into it last time, I couldn't figure out where intellisense determined its position. I can try and look into it again sometime this weekend for sure.
No news from VSC Team.
@SneakyFish5 Did you send a PR ?
Here is an interesting case, a simple method in a type script, yes, I know that I have already returned the value above, but in spite of this, I continue to write the code, I want to delete the above code later, it is more convenient for me. But due to this stupid pop-up system, I am unable to write in the editor until I follow the order of the text editor.
I can only advise increasing the tooltip delay ->
I would love to be able to offset the tooltip. By pixels or percentages. I am a new coder and the help seems really helpful at times. In my thinking, a person who relies on the tooltips certainly doesn't need it covering up the code they just wrote.
Obviously, allow a setting to offset the tooltip to whichever position the user decides to set it at.
Default behaviour for any kind of program that accepts text, whether it be a word processor, code editor, in-browser UI should be that not paying attention to visual feedback (or not being able to see, whether due to human accessibility issue, or due to computer lag) does not obstruct the user from doing what they are doing.
It says a lot about Microsoft as an employer that this point, which seems to be obvious to 90% of devs, has not been acted on :/
It makes one wonder if coorporations are trying to maintain a certain number of annoyances on open source software after making it good enough to slow down independent open source alternatives... but why??... what possible reason could there be?... ;-)
+1 for positioning offset: top/bottom/left/right, with percentage or pixel distance (spacing)
This drives me so mad. Hate it when the IDE gets in the way of just getting on with coding.
I'm writing to support this issue, I think the offset would be a good solution.
I have been using vscode for a while now and this is the biggest pain point - can't believe this has been open for 4 years
some intelligent way to only show these hints for rarely used functions or not show again for the same function if the user has already closed by esc
Not that I know what I'm talking about, but this seems like something really simple to implement...
Nobody (I think) suggested it but... why not make the popup draggable ? Sometimes you don't care about the code before, sometimes you do. Just let the window popup like it is right now and allow the popup to be dragged out of the code you want to see. After the popup is closed, it resets the position as default for the next one.
Instinctively, the first thing I tried when I needed to see the code under the popup was to try to drag it out of the way. After 20 minutes of looking at the settings to change the behaviour, I made a Google search and ended up here.
So, simple solution: make that popup draggable ! It even highlights with a blue contour when you click on it, so the events are there.
why not make the popup draggable
Like that a lot!
why not make the popup draggable and dockable
Currently the parameter info tooltip is always placed above the cursor. This is often quite annoying since it completely blocks code in the above lines and you sometimes need to look at your context to know what values to give the parameters.
Example: