>> ..ghci is able to generate the tagsfiles for you. This allows you to
>> jump to definitions of identifiers.
>> If you go this route, I will shamelessly promote hothasktags instead
> of ghci. It generates proper tags for qualified imports.
What do you mean by "proper" here? GHCi has the information
needed to generate more detailed tags, but the tags file format
did not support much more detail last time I checked.
Tags for explicitly qualified names could be generated (and
probably should be), though that would interact with the default
identification of Haskell identifiers in Vim. But if you want to
resolve imports properly (or at least a bit better, such as adding
"import qualified as" support, or pointing unqualified uses to
the correct import), you need more support from the tags
mechanism.
There is a tags file format proposal here:
http://ctags.sourceforge.net/FORMAT
that does (among other scopes) suggest explicitly file-scoped
local tags
file: Static (local) tag, with a scope of the specified file.
When the value is empty, {tagfile} is used.
but in Vim 7.2 the help file still says
http://vimdoc.sourceforge.net/htmldoc/tagsrch.html#tags-file-format
The only other field currently recognized by Vim is "file:"
(with an empty value). It is used for a static tag.
If Vim somehow started supporting that extended file:<scope>
format without updating its docs, that would be good to know
(what version of Vim? where is this documented?).
Your suggested use-case for such a feature is interesting, but
we're getting into an area where "live" calls to a scope resolution
tool might make more sense. If one is willing to depend on
Vim's Python-binding, one could keep a GHCi session live
in the background, track the current file/module, and use the
":info" "-- Defined at" output to find the correct definition.
Btw, GHCi's ":browse!" gives information on where available
names come from, which can be useful for resolving unqualified
names (which "map" is that?) in unknown code.
Claus