getHovers does not return useful information for an import prefix

[DanTup]

Given this code:

import "dart:async" as x;

main() {
  var a = new x.Future();
}

If you send a hover request for the x at the bottom you get this:

{
	"id": "212",
	"result": {
		"hovers": [
			{
				"offset": 148,
				"length": 1,
				"containingLibraryPath": "/Users/dantup/Desktop/Dart Sample/bin/main.dart",
				"containingLibraryName": "",
				"elementDescription": "as x",
				"elementKind": "import prefix",
				"isDeprecated": false
			}
		]
	}
}

There's no information in there to say that this import was for dart:async so it's hard to render a useful tooltip. If I hover over dart:async I get a bunch of information including the dartdoc for the library. It's be nice if we could have this here to show the user information about what x is.

[srawlins]

Still relevant; no tooltips for prefixes.

[FMorschel]

Working on https://dart-review.googlesource.com/c/sdk/+/390960. I made it work but the current output is not great, still needs some thoughts.

[FMorschel]

Something else that crosses my mind today (haven't tried anything just yet) is what should we do when two imports share the same alias?

Something like:

import 'dart:core' as dart;
import 'dart:async' as dart;

When hovering on the acual import line we can differentiate easily enough, but not necessarily when inside the code if both import export a shared top level declaration (say flutter/cupertino and flutter/material both export the base widgets like Text) or when you haven't written the second name yet. Any ideas are welcome.

[DanTup]

I'm not sure what to do in the case of getHover (which is what the request was initially for, but VS Code no longer users). It might be difficult to do a lot in the case of multiple without protocol changes. Maybe we should either show the first one, or not show anything when there are multiple?

For VS Code / LSP, we're not tied to specifics of the protocol because we're just returning Markdown, so we could probably just duplicate whatever string we should for one when there are multiple.

[bwilkerson]

We aren't likely to make changes to the legacy protocol to support this. If clients that use the legacy protocol want to support this they could choose to use the LSP request instead.

[FMorschel]

I think the CL is basically working. Does anyone want to review it (or to suggest someone) or should I add you both since you're here on the issue?

[DanTup]

@FMorschel thanks! I didn't notice in the CL but the text here is wrapped in triple backticks so it has language syntax highlighting applied to it (eg. for is coloured and it's a fixed width font):

I can easily fix, but thought I'd ping you in case you wanted to first :-)