Skip to content

[Feature Request] Hover Docs for function arguments/return types #2258

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

Closed
konn opened this issue Oct 6, 2021 · 5 comments
Closed

[Feature Request] Hover Docs for function arguments/return types #2258

konn opened this issue Oct 6, 2021 · 5 comments
Labels

Comments

@konn
Copy link
Collaborator

konn commented Oct 6, 2021

Currently, hover documents for functions shows only haddock comment associated for a function, without haddock comments of their arguments or return types.
It would be great if we could show documentation also for arguments and return types.

If someone would give me some hints, I would love to implement this feature!

There are some design choices where to print such documentation: along with type document, dedicated table or some view.

@jneira jneira added component: ghcide type: enhancement New feature or request labels Oct 6, 2021
@konn
Copy link
Collaborator Author

konn commented Oct 10, 2021

I've just started experimenting around this here: https://github.com/konn/haskell-language-server/tree/argument-haddocks.
As I haven't implemented desired feature itself yet, so I have not opened pull req for the time being).

It turns out that it is relatively easy to retrieve argument documents from HIE files.
The remaining (not so non-trivial, but rather tedious) parts seem:

  • Recovering the correspondence between the argument types and their documents
    • We need to correctly strip quantified variables and constraint arguments correctly; I haven't found the exact procedure to determine the corresponding type with the given index in mi_arg_docs.
    • What if forall-quantifier appears in returned type and haddock comments are placed for the types inside the quantifier? Is it banned, or just counted as the ordinary cases?
    • We need to decompose IfaceTypes, not only Types, which doesn't provide smart deconstructors like splitFunTys for Types, so we have to implement it first.
  • Pretty-prints it aside with the argument/return types.
    • We have to decide the appropriate style of documentation.
    • We must pay attention to number only vanilla arguments (i.e. non-dictionary arguments).
    • As arrows (->) can be annotated with multiplicity since GHC 9.0, we need to be careful to implementing prettyprinting procedure.
  • (Optional) Alternative parsing implementation in the case of HieFresh.

@konn
Copy link
Collaborator Author

konn commented Nov 14, 2021

Superseded by #2348.

@konn konn closed this as completed Nov 14, 2021
@Anton-Latukha
Copy link
Collaborator

Oh, sorry. I had no idea it was not in HLS. I thought it should be downstream somewhere in LSP chain so I send the request into the haskell/lsp & it go transfered into HLS. & the day before the transfer, I was looking at the code about it.

Today I try to stay away from programming. I know this is important to have. I would strive to finish the main process on the week.

@konn
Copy link
Collaborator Author

konn commented Nov 15, 2021

No problem! I certainly need this feature, but I have less time to spend on it. So really appreciate you for working on this feature! I hope the information noted above could help your process. Thanks!

@Anton-Latukha
Copy link
Collaborator

Wanted to clean-rebase/cherrypick your commit:

Screenshot-2021-11-16-20:12:25

Can not cherrypick it clean & because I would change it much - the signature authorship would change.

So would redo & attribute work in the commit.

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

No branches or pull requests

3 participants