The good reason is that you do not actually want to have to specify all the options that you need to get your program to compile, merely to get tag information. To generate the tags for dazzle using ghci I need to use echo ":ctags"| ghci -v0 Main.hs -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec whereas with hasktags I'd just use hasktags *.hs
yes, that's a general problem with using ghci in real projects. of course, *.hs isn't always sufficient to find the files for a project, and the files might need pre-processing, etc. but there are advantages to not having a proper parser and just treating a project as a collection of files, to be found by globbing or find, and to be scanned for some simple patterns. it means that one can get tags for incomplete projects, even with errors in the files. but as far as the extra options are concerned, i tend to create a miniscript to set the options for a project, and use the fact that --make/--interactive switch between ghc and ghci: #!/bin/sh ghc ${mode:-"--make"} $@ -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec then, to build with ghc: ./myghc.sh Main.hs or, to invoke ghci: mode="--interactive" ./myghc.sh Main.hs or, to generate tags from outside ghci (this might be worth a command alias): echo ":ctags" | mode="--interactive -v0" ./myghc.sh Main.hs such scripts wouldn't be needed if ghc/ghci could be started from cabal files - you'd just set your options and paths once and for all (there's a ticket for that somewhere). once I'm set up in ghci, as I tend to be while hacking, it is of course just :ctags rather than finding a shell and typing find . -name *hs | xargs hasktags or somesuch;-)
What I would *really* like is a Haskell parser in Exuberant Ctags... that would mean I could directly use vim's taglist extension.
another good point, but: exuberant ctags is just another tagfile generator. it is very good for other languages, but *really* teaching it about Haskell is non-trivial. whereas ghci or ghc-api already know how to type things and all the rest of Haskell's static semantics, in addition to parsing things.. as for using taglist: do you mean the vim function taglist, which gives you a dictionary with information associated with a tag? so you are probably interested in extra information about tags, beyond source location. (*) it should be a lot easier to expand the information generated by :ctags than to add a Haskell parser/type checker to exuberant ctags. the format is simply a comment (to protect old vi from choking on the extra info) followed by a list of extra fields (the dictionary) for each tag. see ":help tags-file-format" in vim, the third variant of the format. the only reasons i didn't do that right away was (a) it was my first serious attempt at using ghc api/extending ghci (Simon M had to do some reworking of my submitted code;-) and (b) i don't know how to use that kind of info in the emacs branch. have a look at ghc/compiler/ghci/InteractiveUI.hs, around listTags/TagInfo. if one knows where to get it, one could add info there (eg, the type of the tag, or whether the tag is a type/class/function/module/whatever). and the extra info ought to be written to the tags file, in collateAndWriteTags (simply ignore the extra info when writing the emacs tag file). hth, claus (*) if you want to go for broke, try ":help cursorhold-example" in vim. that will keep a preview window with the source-location of any tag your cursor remains on for long enough. so you might see the type declaration, or you might see the data type constructors belonging to a type, or .. i haven't used this as a default myself, but it is worth looking at at least once!-)