Expose InlayHint API to Rascal DSLs

[DavyLandman]

Decorations (or soon to be offered as InlayHints) are a nice way to provide the DSL user with more context (just like the gitlens extension does).

Currently, it's not exposed in LSP (see: lsp#956 and: vscode-imp#772). I want to propose we still add it to the LanguageService adt.

As I understand it: VSCode (and later LSP) is getting InlayHints api in the future, which are more constrained version of Decorations. Until we get native inlayHints in LSP, we can simulate it by sending Decorations to the IDE.

[jurgenvinju]

looks very useful indeed; have to think about when and how people can register them. With code lenses we've chosen a mostly synchronous version where lenses are registered after parsing. However, for these decorations it could also be very useful to add them while debugging a program, for example. There are "live programming" extensions to VScode which use decorations to show the current value of a variable.

So, the general addition to the LanguageService adt is probably simple and useful, but we should think if we also want to add this feature to IDEServices as well, analogous registerTextEdits..

[DavyLandman]

agreed, we could think of more interactions, like the live-debugging style.

[DavyLandman]

Just for now, we have no dynamic interactions as part of our language bridge yet. So when we get to debug protocol, well rethink this.

[jurgenvinju]

Yes we do have dynamic interactions over the LSP bridge; for example registerTextEdits is a dynamic interaction and the visuals via WebView as well, and the execution of commands, etc.

But we can delay this kind of interaction for the current feature. I'm fine with that.

[DavyLandman]

Current status: the static aspects are merged, in the future we can think of more interactions between annotations and the DSL. However, we have to think about triggers for those interactions as well.

A consideration for the future might be to move these hints to the summary?

[jurgenvinju]

Yes, moving these into the summary makes sense, optionally. That way people can safe time by constructing this relation together with the others.

On the interactions note: if we include this feature in IDEServices, then people can code trigger these interactions in any way. This is similar to the registerTextEdits feature. It puts a strong pressure on implementing such IDEServices properly (i.e. thread-safe).

[jurgenvinju]

Let's close this issue for now? It's there!

[DavyLandman]

On the interactions note: if we include this feature in IDEServices, then people can code trigger these interactions in any way. This is similar to the registerTextEdits feature. It puts a strong pressure on implementing such IDEServices properly (i.e. thread-safe).

True, that would mean changing the API from the VS Code side, but we could think about that in the future indeed.