The go-to definition function compares the highlighted text with modules in the cabal file.
If there is a match, it takes the respective build target and tries to fetch their hsSourceDirs from the PackageDescription. (by looking at all buildInfos with matching names).
After finding them, it constructs a path using directory where the cabal file is located, the info from hsSourceDirs and a name of the module converted to a path.
If the file exists it returns the Definition with the acquired location.
What isn't implemented
[x] No tests
[x] Current solution can't differentiate modules with same names.
[x] Current solution to choose if a definition can be provided isn't great, and is just a chain of if's
[ ] The range in location is just zero, instead of highlighting the name of the module.
Noteworthy change:
Split one large gotoDefinition function to multiple specific ones.
This will hurt the performance a little bit, but hopefully make the addition of other definitions easier.
Go to the module's definition
If you click go-to definition on the field under
exposed-module
orother-module
it will open the file where this module was defined.Video with an example:
https://github.com/user-attachments/assets/c5cdcb9e-4d24-4d6b-a83a-de34d8dcedf6
Implementation details
The go-to definition function compares the highlighted text with modules in the cabal file. If there is a match, it takes the respective build target and tries to fetch their
hsSourceDirs
from thePackageDescription
. (by looking at allbuildInfos
with matching names).After finding them, it constructs a path using directory where the cabal file is located, the info from
hsSourceDirs
and a name of the module converted to a path. If the file exists it returns theDefinition
with the acquired location.What isn't implemented
if
's