Hover should show all signature info. Consuming something should only show contextual info.

[cartermp]

This is inspired by a discussion with @dsyme in #1895.

The current behavior of F# is as follows:

• Hovering over something shows only the Summary XML doc content and exceptions.
• Using something (e.g., passing a parameter into a method) shows info about all parameters in addition to contextual info about the parameter you're dealing with. This is a duplication of sorts.

I believe that this should be flipped - hovering should show all info, and using something should show contextual info. Here's what that looks like.

Hovering over things:

Consuming a thing:

What are your thoughts?

[vasily-kirichenko]

As Don said, the more info the better. What about showing everything we have in both cases?

BTW, why "aString:" and "This is the string..." are not on the same line?

[cartermp]

I disagree that more info is better in the second case if you can get all the info by hovering with the mouse. The current behavior has no way to get all info just by hovering, so only showing one parameter at a time could make things difficult. But if that ability to see all XML doc info exists on hover (which, I think, is the more likely action someone would take if they're looking for information about something), then I think we can do away with the duplication when consuming the member/Type Provider. With members which have many parameters, that becomes a lot of information which:

(a) doesn't look good, and
(b) could even be detrimental by presenting too much information when someone doesn't need that information.

BTW, why "aString:" and "This is the string..." are not on the same line?

Unsure, since the existing code just passes the TextSpan of info into the Roslyn API. Probably something wired up a bit funny.

[dsyme]

I agree the displays are messed up. At some point we need to do a complete revamp of the visuals for Quick Info, method overloads, declarations.

if you can get all the info by hovering with the mouse.

Right now you only get one overload with the mouse - the first, and it's not usually adequate, In contrast with method tips you get all the detail of the overload you've selected. There's no other way to get all that detail short of looking up the docs or going parameter-by-parameter

[cartermp]

I see. It sounds to me like right the solution is to enable:

• f1 wired up
• f12 and alt+f12 let you go to/inspect metadata showing overloads

I'm just not a fan of showing all information when you're mid-consumption. I don't think that "I want to know everything about what's going on with this overload" is the kind of thing most people are doing when they're in the process of consuming an overload. Perhaps a case could be made for when you first type (, but certainly not when someone is typing in their third parameter. Typically it's more along the lines of "I need to choose this particular overload, let me cycle through the overloads to go and find it". Having XML doc comment info about every parameter at all times feels unnecessary:

Having this behavior due to not having the above features seems like a reasonable point-in-time solution, but I don't think it's the right place to be if we have those capabilities.

[dsyme]

@cartermp Oh also just to mention that in VS2010-VS2015 the highlighted parameter is shown in bold (instead of repeated). If we could get Roslyn to do that it would be great

Having XML doc comment info about every parameter at all times feels unnecessary:

For that example yes indeed :) Though it's not totally a typical example

[isaacabraham]

I'm inclined to agree with Phil here. As long as you can mouse over / CTRL K I to get the full information, I'd personally prefer to just see the current argument when calling a function.

In this case I think less is more.

[isaacabraham]

A good example of this is the ARM type provider I've been working on. Sometimes methods are generated with dozens of arguments - showing the full argument list in the info pop up is a pain. I'd much rather just see the detailed info for the current argument.

[dsyme]

@isaacabraham @cartermp Now I'm weighing up whether we fully trust our current-argument implementation :)

[cartermp]

@dsyme What do you mean? From what I can tell (at least with my PR), the current argument seems to be accurate for method overloads.

[dsyme]

From what I can tell (at least with my PR), the current argument seems to be accurate for method overloads.

That's good to know. I think for a while (way back) the current argument computation was dodgy.

[cartermp]

I'll try it out with some more overloads. Seemed to work fine with my own types, String.Concat, and Console.WriteLine.

[cartermp]

@dsyme Trying it out more, things seem to work just fine. Behavior seems to match that of C# when typing out arguments. For example, when typing the second argument to Console.Writeline, both C# and F# default to overload 14. I haven't found any discrepancy in the current argument thus far.

@vasily-kirichenko Regarding you comment here: #1949 (comment)

This is easily addressed if we build tooltips in the Roslyn style. We have our own homegrown XML documentation code which appends newlines in various places which is affecting us. It's easy to remove those, but it will also then look awkward with Roslyn highlighting the current parameter unless we have a small hack which places a one-time newline between the list of all arguments and the current argument being highlighted.

I have a fix out here, which doesn't show all arguments, and it looks like this:

[dsyme]

@cartermp That looks good. I'm happy to roll with that