Consider these two almost identical specifications.

Model.EntityTypeDef = <
  <EntityOrRelation> <ID> {
    <RoleOrAttribute*; separator="\n">
  }
>
EntityOrRelation.EntityType   = <entity>
EntityOrRelation.RelationType = <relation>

and

Model.EntityTypeDef = <
  entity<Placeholder1> <ID> {
    <RoleOrAttribute*; separator="\n">
  }
>
Placeholder1.EntityType = <>

Model.EntityTypeDef = <
  relation<Placeholder2> <ID> {
    <RoleOrAttribute*; separator="\n">
  }
>
Placeholder2.RelationType = <>

These parse exactly the same programs and produce exactly the same AST.

However their hover behaviour is different.
In the first case hovering relation hovers the AST node RelationType, while in the second case hovering relation hovers the AST node EntityTypeDef.

While the first syntax specification is clearly better, its hover behaviour is undesired. Hovering relation is useless.

Solution

I propose that we add a {no-hover} directive to AST-nodes such that hovering them will actually mean hovering their parent.

We could do this in SDF:

Model.EntityTypeDef = <
  <EntityOrRelation> <ID> {
    <RoleOrAttribute*; separator="\n">
  }
>
EntityOrRelation.EntityType   = <entity>   {no-hover}
EntityOrRelation.RelationType = <relation> {no-hover}

Or, if this is not really SDF specific adding a strategy for hover that would allow fetching the parent for certain constructors.

no-hover: a@RelationType() -> a

Submitted by Daco Harkes on 13 June 2014 at 16:35

Implementation-wise this has to do with origin-tracking.

The origin of relation is different in both situations, thats why the hover behaviour is different.

I don’t think changing/extending SDF is the solution here. The proposed “no hover” would be an ad-hoc extension. But what is the general issue here? I assume generic versus specific hover behaviour. The generic one does not do it in your specific case, why you want to specify an alternative behaviour. I assume the hook Spoofax provides is linked to a generic implementation and which can be substituted with your own solution.

Your latter proposal might suggest a customisation option for the generic implementation. Currently, you have to replace it completely with a specific solution. In your case, you are fine with the generic solution in most cases, with only a few exceptions.

I think you are right. A specific hover implementation would make more sense. For a specific hover implementation we would need a stratego call that allows one to get the parent of an AST node though.

On the other hand, if there are more editor services tied to the origin mapping between text and AST nodes, then it would actually make sense to have directives that influence this mapping. The properties view has the same issue, but that is the only thing I can think of. (And I suppose directives to influence origin information might break other stuff.)

Specific hover implementation is the correct way to go here. Closing issue.