Incorrect highlighting in hover in VS Code

[sheaf]

I have noticed the following issues in hover highlighting in VS Code:

1. Type highlighted as a value.
   

2. Multi-line type signature incorrectly highlighted.
   

As one of the maintainers of the VS Code syntax highlighting extension I'd like to figure out how to go about fixing these issues.

Could someone let me know how the hover syntax highlighting works in VS Code, i.e. which part of the code is responsible for generating the content of the hover boxes, and in what way is the syntax highlighting engine being called? Then I can try to solve the above two problems. Edit: this appears to be at Development.IDE.Spans.AtPoint.atPoint in ghcide. Going to experiment.

Let me know if you come across any other issues with hover syntax highlighting.

[sheaf]

What I've gleaned so far:

• for a type, Development.IDE.Spans.AtPoint.atPoint gets the GHC.Types.Name.Name of the given source span, uses Development.IDE.Spans.Common.showName to turn it into Text, and then simply puts that in a Haskell markdown code block:
• for a value, either the type is a literal, or it's again given by a GHC.Types.Name.Name in which case it does the same as above except it also appends a type annotation.

Issue (2) in the OP can readily be fixed by adding extra spaces on the subsequent lines for the type annotation.

For issue (1), I don't know what's best. We could preface the type being hovered over with the text type , which would fix the highlighting but might confuse users, making them think it's a type declaration. We could preface the type with the appropriate declaration (e.g. type , type family , data , data instance , newtype , newtype instance , class ) which seems like a nice idea except I'm not sure what to do for type variables (possibly nothing, not too problematic). Note that currently hovering over parenthesised expressions like (F a b) doesn't create a hover popup, so we don't have to worry about the TyConApp case. We could also preface the type with _ ::, but that doesn't seem very clear to me either.

[ndmitchell]

Thanks for getting in touch @sheaf - great to have a line of communication with you!

For (2) I would have thought the pretty printing has prefix spaces in it. So are we losing them? That's a definite bug and it would be great to fix.

For (1) prefixing with type regardless seems grim and confusing. Prefixing with type, type family get seems like useful context, so that seems like a good idea Would also be good to include any type arguments, e.g. data Maybe a. Type variables are a bit of a pain, but also there's no additional context to be had, so I'm not too upset if the highlighting isn't perfect there.

I think we will have expressions eventually, but not for a while, so I'd not worry about it until then.

[Anton-Latukha]

Would work on it soon through #2348 work. To be able to show documentation of arguments - would need to layout arguments first.