Explore improving UX for IntelliSense

[miguelsolorio]

This exploration will aim to unify the IntelliSense features (hovers, completions/suggest, parameter hints) in style and content. Additionally, we will explore to address the positioning of parameter hints (currently shown above the cursor).

Related Issues

• Shorten method signatures Shorten method signatures (aka "type madness") TypeScript#14662
• Better structure for IntelliSense Completion details should have syntax highlighting #50813
• Add opacity setting for IntelliSense Add opacity/transparency setting for intellisense suggestions popup #22439
• Better positioning of popup Editor hover can overflow to top of screen #60534
• Add syntax highlighting to suggest widget The signature in suggestion widget should have syntax highlighting #60651

Current Design

Explorations

Exploration A

• Moves parameter hints below cursor
• Combines parameter + suggest widget
• Reduces opacity of entire widget to 95%

Exploration B

• Same as Exploration A
• Increases width of widget to show single line
• Aligns widgets based on cursor

Exploration C

• Same as Exploration A
• Aligns widgets based on cursor
• Adds parameter hints inline as shadow completions

GIF Example

[chpxu]

I'm all for C, only problem I see is if you don't fill in all parameters, say only 3 out of the ones in grey text, it could perhaps auto adjust to the ones filled in?

I also feel that the code shown in the beginning is all a scramble, as the case has been for a while, I and many others could. benefit from a more prettier layout (as in the hint code)

[eamodio]

I definitely like Exploration C the best -- the alignment seems better ( but would love to try it to get a better feel for it), and I really like the parameter hints. Although I can see overloads being a challenge there.

I also have to say I really don't like the opacity exploration -- unless the opacity became full as soon as you navigated the list (otherwise I feel like it make it harder to parse, since you get competing text below it). Although a blurring effect could help with that, but then I don't see how that would improve over a full opacity.

At the same time, I do like what VS does -- have a hotkey (they use Ctrl) to make the popup very transparent (so that you can see underneath it) on demand.

[miguelsolorio]

...say only 3 out of the ones in grey text, it could perhaps auto adjust to the ones filled in?

@beastdestroyer can you expand on this?

@eamodio thanks for the feedback, we really do appreciate it! For the opacity change, there were two ideas that we discussed:

1. Create a setting that would allow a user to configure how much opacity they'd want to set the entire widget to (not everyone will want this feature)

2. Auto-dimming the widget on a key command (just like you mention in VS) where the opacity goes down low (~10%).

[benfrain]

C. As an aside is it worth considering performance at this point? I’d imagine opacity is going to have some cost over fully opaque. I’m not suggesting ruling it out prematurely on that basis but perhaps something to keep in mind

[eamodio]

@misolori no problem! Those options sound good (especially since they are opt-in/out) -- although I still do think opacity without some blurring just ultimately hurts the readability.

[Da13Harris]

All the options appear to be an improvement IMO. As long as the pop-up widget is generally positioned below the cursor, I'll be pleased. As it currently stands, it often covers code above the cursor that I'm trying to reference.

FWIW, I really like option C. It saves visual real-estate and reduces complexity of parameters that are already complete. I could, however, imagine some issues when re-visiting a method with parameters that have already been completed. Maybe it could include a "subtle" UI toggle feature to show/hide the method signature?

[chpxu]

@misolori For example, say you filled in fileBackup, then matchingString but skipped all the way to maximumBytesToRead. I'm sure there would have to be a way to detect which values are for which parameters

EDIT: By prettier layout, instead of readToMatchingString(file: string, matchingString: string, chunkBytes: number, maximumBytesToRead: number): Promise<string>

It becomes

readToMatchingString(
 file: string,
 matchingString: string,
 chunkBytes: number,
 maximumBytesToRead: number
): Promise<string>

Or any other clean vertical format, since people prefer vertical reading than reading horizontally; and it'd look nice. This would look nice on A

[siennathesane]

Honestly, I like B more since it leaves more room for more functions with more parameters.