...

suggests using :etags in GHCI or hasktags, or gasbag. Of the three, hasktags comes closest to "working" but it has (for me) a major inconvenience, namely it finds both function definitions and type signatures, resulting in two TAGS entries such as:

Some customization required? Tweaking the output format is usually the easiest part of a tags file generator. Alternatively, add information about the kind of tag, have both tags in the tags file, and do a little filtering on the editor side (in Vim, try ":help taglist()"), so that you can go to the type or value level definition with different key combinations.

I'm also a user of the one true editor (namely vim ;) and I'd be interested in an answer to that too. Every once and a while I go look at the various tag programs to see if there's anything that works better than hasktags. The continuing proliferation of tags programs implies that others are also not satisfied with what's out there, but no one is devoted enough to the cause to devote the effort to make the One True Tags program.

Some notes from someone who has written his share of tags file generators: 1. there are trade-offs to consider: fast or detailed? incremental (file by file) or tackle a whole project at once? should it work on syntactically incorrect code (regexes, parsing, or parsing with recovery)? how much detail can your editor handle, without requiring extra scripting (emacs tags files can't hold as much info as vim tags files can - the latter are extensible; but to make use of that extra info, scripting is required)? 2. once you reach the borders of what quick and dirty tags generators can do, things get interesting: haskell-src-exts makes it quite simple to generate top-level tags with proper parsing, if the file can be parsed; GHCi knew about top-level definitions anyway, so it was easy to output that as a tags file; but what if the file cannot be parsed? what if the import hasn't got any source (not untypical in the world of GHC/Cabal)? do the interface files of the binary modules have source location info?? how to handle GHC/Cabal projects, not just collections of files? 3. what about local definitions? what about non-exported top-level definitions? Here the editors get into difficulties handling too many tags without distinguishing features. As it happens, I've recently released support for (lexically) scoped tags in Vim, with a generator for Javascript source: http://libraryinstitute.wordpress.com/2011/09/16/scoped-tags-support-for-jav... I'd love to see a scoped tags generator for Haskell (the scoped tags format is language independent, and the Vim script support could be reused), but that would double the size and complexity of a simple parsing tags generator (beyond traversing top-level definitions: traversing expressions, handling Haskell's complex scopes) or require additional code for a GHCi-based generator (of course, a regex-based generator would fail here); also, the Haskell frontend used would need to record accurate source spans; I'd also like to see type info associated with scoped tags, for presentation as editor tooltips, at which stage the air is getting thin - parsing alone doesn't suffice, so you need parsing, type-checking, and generic scope-tracking traversals of typed ASTs, with embedded source span info; perhaps an application of scion, but by then you're beyond simple; and all that power comes at a price of complexity, speed and brittleness: no tags if parsing or typing fails, where the latter requires reading interface files, or handling whole projects instead of isolated files.. Perhaps combining a quick and dirty incremental tags generator with a detailed and sound full-project generator could do the trick? Or, you could drop the tags file generation and treat the detailed and sound full-project analyzer as a server which your IDE/editor could ask for info about code, while reloading only those files that change (as if the language query server was a programmed GHCi session running in the background). Which seemed to be the direction scion was heading in.. https://github.com/nominolo/scion Tags files are a nice interface between language-aware generators and general purpose editors/IDEs, but they are limited. I still think it is worth using them, in extended form, but if your editor doesn't make such extension easy, or if you want to leverage the complex language frontend for other purposes, switching from offline tags file generators to online language query servers makes sense (even back in the C days there were both ctags and cscope). I hope this helps to explain why there is no One True Tags program? Claus http://clausreinke.github.com/