hasktags - small patch

[Claus Reinke]

> 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!-)