Jump to definition of symbol

[adam-singer]

A feature request, if not already requested, adding support to jump to definition of symbol even if dependency. A nice feature that exists for haskell-vim-now (codex + hasktags) is the ability to have ctags generated for project and dependencies to do navigation.

Would be nice if that was out of the box support with intero instead of baking up own solution.

[chrisdone]

I think with stack haddock we could hypothetically figure that out. I'd rather not generate tags from source when Haddock already knows how to link up symbols to their source.

[mgsloan]

Yup, definitely something I'd like to see as well. Currently stack unpacks source to a temp dir, best solution for this would have it leave the source in a location (read-only?)

[IvanMalison]

@chrisdone How exactly do you imagine that this would be implemented. This is something that I'd really like to see, and I have some extra time so I'd love to help out however I can.

[chrisdone]

Intero has the package name and version when you try to jump to definition. So Intero could run stack unpack on that exact version into .stack/sources or whatever the correct location is. Then the problem is finding the right file. GHC might have original file info, might not. This is the key question mark. Once you have the file Emacs can jump to it. This will cause Intero to start another session for that project and load it up too. With the recent Intero blacklisting support, you could disable that if the projects you're looking at are large. That's as far as I got.

…

On 27 Nov 2016 07:21, "Ivan Malison" ***@***.***> wrote: @chrisdone <https://github.com/chrisdone> How exactly do you imagine that this would be implemented. This is something that I'd really like to see, and I have some extra time so I'd love to help out however I can. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAArC2aFn9pxFJESDzLSZcl-m4_SyDoAks5rCSF_gaJpZM4Jj-er> .

[chrissound]

In the event it is useful: this functionality is present in the intellij plugin: https://github.com/rikvdkleij/intellij-haskell

[SamuraiJack]

+1 for this feature (already implemented in the IntelliJ plugin)

[jesuspc]

+1

[kRITZCREEK]

Stop this. Github introduced the 👍 button for exactly that reason. You're just creating noise.

[matthew-piziak]

That may be the point. I am not surprised that people really want basic navigation.

[matthew-piziak]

@chrisdone I'm guessing this is marked as priority: low because of blocking difficulties (#231 (comment)) and not because the feature is not deemed important, is that right? Are there any new developments since last year that might make this more possible now?

[mgsloan]

I don't think there are new developments here. This is actually quite an involved feature to implement. Don't let that dissuade y'all, though. If someone wants to implement this, it'd be greatly appreciated by everyone!

[matthew-piziak]

Thanks @mgsloan! I don't mean to understate the difficulty of course. :)

[yilinwei]

@chrisdone I've been taking a look at this at the same time as #129 and was wondering whether you knew of a better way that going to the using haddock generated html files to get the line info?

Would that still be an acceptable way of doing it?

[mgsloan]

@yilinwei It may also be worthwhile investigating if the .hi files have the requisite info, I'm not sure if they do, but perhaps they should!

Last resort would be to run intero on every dependency and output a metadata file. Could get tricky for running it on builtin libraries. This could be useful for other reasons, though. Some info definitely isn't in .hi files, such as "find usages". Imagine if you could use "find usages" to find all usages of an identifier in your dependencies, possibly all usages in the entire stackage snapshot. This would be really powerful! I feel like I've written something about this before, but can't find it easily with a search of this repo's issues.

Could even consider distributing these metadata files, but that is frought with problems because they may depend on selection of flags, may even depend on dependencies. Due to TH, could depend on practically anything.

[IvanMalison]

@yilinwei It may also be worthwhile investigating if the .hi files have the requisite info, I'm not sure if they do, but perhaps they should!

I'm pretty sure that they don't, but I agree that they should. It wouldn't be hard to make a change to ghc to add this would it?

[mgsloan]

It wouldn't be hard to make a change to ghc to add this would it?

Probably not! Likely worthwhile. It'd probably be good to add support to ghci / intero as part of that, as it might be hard to get it merged without a concrete application.

I am rather partial to generating a metadata file, but that should also happen in ghc. Otherwise we'll need to build the deps twice just to generate metadata - ugh