Use Hackage for Documentation and Source links

[Saizan]

This is enabled by the new linkToHackage configuration option.

This is useful if you don't have local documentation or sources built, or other minor downsides of using local files. The vscode-haskell provides similar functionality but by trying to mangle the local file links, which is error prone because the path structure has changed between ghc versions.

If local documentation/source exists it gets used as a hint for which module to link to, which generally gives better results in case of re-exports. Otherwise we pick the module where the name is defined, and generate the link using its package name and version.

I am quite unsure if how I wired in the linkToHackage config option is appropriate. But I didn't want to do any refactor without some feedback first.

Initially I figured linkToHackage should be a plugin config for ghcide-hover-and-symbols, but the flag affects the GetDocMap rule which structurally appears to be more part of the core? The first way I wrote it I got import cycles so I backed off.

I am happy to have the flag where it is or move it if desired. And in any case I will split it into linkDocToHackage and linkSrcToHackage for flexibility.

[fendor]

One suggestion and can we add a regression test case, somehow to make sure this doesn't accidentally break?

Otherwise, LGTM :)

[Saizan]

@fendor I got a bit lost trying to add regression tests, would it look something like the ones in FindDefinitionAndHoverTests ?

[vidit-od]

@Saizan Overall looks good,
regarding regression tests,

what you linked is a good pattern to follow, but from what i could see,
FindDefinitionAndHoverTests will use LinkToLocal by default. You'll need to write a separate test function that uses testithconfig with a custom Testconfig that sets to LinkToHackage maybe

[fendor]

LGTM, thank you!

I am wondering what the default should be and we need to add it as a vscode config as well, so the users can change it...

Should the default be LinkToHackage or do you prefer LinkToSource?

[Saizan]

I have been using LinkToHackage because I often don't have the local versions, however I figured we'd leave the old behavior as default

[vidit-od]

Looks good to me as well !! LGTM !!

also, LinktoSource seems like a good default to me.

[fendor]

also, LinktoSource seems like a good default to me.

In VSCode, this links to an HTML page which is not rendered, so I don't think that's a good default.

Screencast_20260515_111823.webm

however I figured we'd leave the old behavior as default

In VSCode, we rewrote this to hackage links, so it is not really the "default".
As the local sources aren't always available, I think we should use Hackage as the default.

---

Thus, I request to change the default to LinkToHackage, but I'll leave it up to @Saizan

[Saizan]

It is properly rendered for me, but the links within it are opened in my actual browser, where they do not not resolve properly.

I'll make LinkToHackage the default for both documentation and source then.