Haskell-language-server: Hover docs for dependencies

Created on 19 Jul 2020  路  7Comments  路  Source: haskell/haskell-language-server

As it stands, it seems that Haddock docs show up for boot libraries, and the project being developed, but not for third party libraries from Hackage.

I would guess (without really knowing anything about the current implementation) that if the dependencies have been installed with documentation (e.g. documentation: True in the global cabal config file), then the logic wouldn't be that different to the way it currently works for boot libraries - i.e. HLS just needs some way to know the path to the .haddock files.

I'd be keen to take a look into this if no one currently is. But I would need some pointers.

can-workaround plugins enhancement

Most helpful comment

@pepeiborra thanks for the clarification about how hls/ghcide hover works.

I think we should update hls itself cabal.project and stack.yaml dropping the documentation flags and adding the -haddock ghc options cause afaik the main goal for adding them was precisely get docs on hover.

I've tested locally that using -haddock show docs but no using documentation: true, did it work for you @fendor?

All 7 comments

A possible workaround is to active documentation generation for all depedent packages adding in the cabal.project:

package * 
  documentation: true

(tip credits for @fendor)
It will make the build really slow but it can be done ocasionally.

The hoogle plugin would add docs for dependent packages included in its default set. In the practice they are quite used so you would cover docs for many deps.

Ignoring the hoogle plugin, currently hls/ghcide glean Haddocks from interface files. For interface files to contain Haddocks, ghc must be called with the -haddock flag.

Unfortunately, I don't believe Cabal currently knows about this ghc flag, regardless of the documentation:True setting [1]. You could work around this yourself by telling cabal to use this flag when compiling dependencies in the cabal.project file, or if using stack, in the stack.yaml file.

For Nix, I have sent a PR [2] to add a setting for this, although it will not be the default until 8.12

[1] - https://github.com/haskell/cabal/issues/6825
[2] - https://github.com/NixOS/nixpkgs/pull/91557

Ignoring the hoogle plugin, currently hls/ghcide glean Haddocks from interface files. For interface files to contain Haddocks, ghc must be called with the -haddock flag.

There is a open issue about implementing the plugin, maybe we should closing it with a note.

Thanks @pepeiborra, I didn't know about that flag!

Not sure what the long-term solution is here then, but for now it seems like it might be worth mentioning in the README that this can be worked around with something like cabal configure --ghc-options=-haddock. Of course, that does cause everything to be rebuilt, and I suspect the build takes a lot longer than without it...

@georgefst better documentation would help, but at the moment my setup is Nix based and I don't use either stack or cabal.project style builds, so I'm not in a good position to give advice about this. If you could send a PR documenting the approach that works for you, it would be a fantastic contribution.

@pepeiborra thanks for the clarification about how hls/ghcide hover works.

I think we should update hls itself cabal.project and stack.yaml dropping the documentation flags and adding the -haddock ghc options cause afaik the main goal for adding them was precisely get docs on hover.

I've tested locally that using -haddock show docs but no using documentation: true, did it work for you @fendor?

As hie-bios can use a specific stack.yaml (and there is a request to be able to set a specific cabal.project), the -haddockoption could be in those specific config files as workaround if the option interferes with normal building (making it slower or fail).
Beyond that the unique way to make some progress (avoid the need to generate haddock docs for all dependencies) would be port the hoogle plugin.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

alanz picture alanz  路  4Comments

wminshew picture wminshew  路  3Comments

davidspies picture davidspies  路  3Comments

jinl0ng picture jinl0ng  路  3Comments

expipiplus1 picture expipiplus1  路  3Comments