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-javascript-in-vim/
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/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
