Currently the resulting node of a reference resolve is passed to the hover strategy. This is not useful in all cases.

For example, consider a variable access that resolves to a property. The hover information of the property might say ‘Property x : String of entity Y’ but the hover information for the variable should be ‘var x : String\nProperty of entity Y’.

One possibility is having two variants of hover:

hover: (resolved-node, hover-node) -> text
hover: node -> text

The strategy should than be called with the pair first, to provide more specific information; if this fail (and for backwards compatibility), the second variant can be tried.
I’ve got this hacked in with dynamic rules and a wrapper around the hover strategy, but implementing this in Spoofax would seem rather easy.

Submitted by Nathan Bruning on 13 April 2010 at 09:59

AFAICT this behavior is caused by Eclipse itself (not Spoofax or IMP): you’re hovering over a hyperlink, so it gives you hover information for that link, not for the text itself. I don’t really like the behavior myself (i.e., I think it should never do this).

I suppose it can be worked around. Not sure how hard that would be.

You’re right that fixing it now would introduce a compatibility problem. I don’t like the idea of introducing a new interface for hover help, since the control rules for all services have the same signature atm (except for analysis). Why introduce a different signature for hover help? :/ Alternatively, we could introduce an annotation to the ESV that says whether or not the referenced node should be returned.

I’m not really convinced by your example though ;) What’s wrong with hover help like “boolean org.eclipse.imp.language.LanguageRegistry.sIsFullyInitialized” as provided by Eclipse? Or “Y.x : String” in your example.

That said, I would prefer if the interface didn’t give you the referenced node since you can still look it up yourself if you get the reference. You can’t do the reverse; only getting the referenced node gives you less information.

Looks like this might be fixable by changing the new org.strategoxt.imp.runtime.services.AnnotationHover class. Not sure if it is used to handle all cases though (would need good testing).

This also causes Spoofax/464…

This is still an issue, can anyone look into this?

The position argument in the tuple of 5 also refers to the def site (incorrectly though, one of the positions refers to annotations triggering errors).

Workaround to at least notice that wrong editor info is being displayed. (For when properties of the variable use site are different from properties of variables at def sites.)

editor-hover:
	(target, position, ast, path, project-path) -> $[[warning][hoverinfo]]
	with
		if Def(_) := target then
			warning := "<b>Warning showing hover info of Definition instead of Use</b><br/><br/>"
		else
			warning := ""
		end
	with
		// get some hoverinfo string

Note that if analysis is not finished yet, actually the ast-node of the reference hover info will be showed (since there is no resolving information available yet).