Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format tooltips using client input #1254

Open
3 of 4 tasks
ettomatic opened this issue Mar 30, 2024 · 4 comments
Open
3 of 4 tasks

Format tooltips using client input #1254

ettomatic opened this issue Mar 30, 2024 · 4 comments

Comments

@ettomatic
Copy link

ettomatic commented Mar 30, 2024

Details

Format tFsAutoComplete should allow customising the rendering for different clients based on client capabilities or client names.

For exaple on Emacs the Eldoc functionlity does not allow to display the exammples section and show a link and a message: Open the documentation to see the truncated examples.

I've initially reported the effect of this issue on emacs-fsharp-mode fsharp/emacs-fsharp-mode#339

Checklist

  • I have looked through existing issues to make sure that this feature has not been requested before
  • I have provided a descriptive title for this issue
  • I am aware that even valid feature requests may be rejected if they do not align with the project's goals
  • I or my company would be willing to contribute this feature
@baronfel
Copy link
Contributor

From the linked issue:

What you're seeing is the result of a design decision to render minimal tooltips inline in favor of rendering something more full in the Info Panel display.

Unfortunately this display is only available on VSCode - what we should do is instead use the information that the client sends us during the Initialize LSP call to determine how we should format tooltips. This would allow us to customize the rendering for different clients based on client capabilities or client names.

@TheAngryByrd / @MangelMaxime any disagreement with this approach? I think ideally we could use some kind of ClientCapabilities structure instead of hardcoding to client names to make these kinds of decisions, but I'm not 100% sure what that would look like.

@MangelMaxime
Copy link
Contributor

No disagreement with this approach.

I believe this is why we also have different CommentStyle:

https://github.com/fsharp/FsAutoComplete/blob/4bc676cc1e8659d9338d31d82d6244bcfcc55cc4/src/FsAutoComplete.Core/TipFormatter.fs#L715-L720

I suppose in the case of Emacs we should the client to say that it wants to use the Documentation style which doesn't have the truncated examples?

Or do we need to introduce a new style?

@baronfel
Copy link
Contributor

I think if we are able to define our own ClientCapabilities you could imagine a setting specifically for which tooltip style to use

"tooltips": {
  "format": "Documentation" 
}

Or any of our other known styles, and we could default to a style that is more inclusive, then have Ionide specifically opt into the command-based style.

That way the behavior isn't tied to the client specifically, and maps to concepts already in our codebase on a forward-compatible way.

@MangelMaxime
Copy link
Contributor

Yes, this is what I think too.

I am just unsure if we already have the style corresponding to:

and we could default to a style that is more inclusive

I also don't remember why I am adding the Open documentation link in 2 steps (format the tooltip and then generate text/link):

Could it be because of the match tooltipResult.SymbolInfo with?

https://github.com/fsharp/FsAutoComplete/blob/4bc676cc1e8659d9338d31d82d6244bcfcc55cc4/src/FsAutoComplete/LspServers/AdaptiveFSharpLspServer.fs#L898-L924

Depending on the reason we could revisit:

 [<RequireQualifiedAccess>] 
 type FormatCommentStyle = 
   | Legacy 
   | FullEnhanced 
   | FullEnhancedWithOpenDocumentationLink // New case
   | SummaryOnly 
   | Documentation 

or in the client capabilities set SupportsInfoPanel which then would allow to generate the Open documentation thing and the info panel capabilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants