hasktags - small patch

[Arthur van Leeuwen]

On 21-feb-2007, at 20:18, Claus Reinke wrote:

>> 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.

I fully concur. And the examples I gave do in fact work for the code
for Dazzle (some 14000 loc). hasktags is quite a bit faster than ghci
as well.

<snip, setting op an environment>

All this should be mapped to a keycombination (<Leader>mt or somesuch)
in your editor, of course. :)

>> 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..

My current thoughts lean toward linking exuberant ctags with ghc-api
in JustTypecheck mode, which would give me huge flexibility, allowing
for e.g. multiple-language projects including Haskell code (one thing I
didn't mention is that Dazzle builds against a C library... :)).

> 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.  
> (*)

I meant http://vim-taglist.sourceforge.net/ which provides a neat  
interface
and some extra convenience. It is somewhat dependent on exuberant ctags.

> 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.

I understand the tags file format. My vim fu is not as strong yours,  
but I
have been using vim since it was at version 4.something and run into  
wanting
to improve the tags at my disposal before.

One of the things a custom tag generator could do is generate not just
hardcoded locations in the tags file, but search patterns. This  
should make
the tags file itself quite a bit more robust against changes, thereby  
obviating
much of the need for dynamic regeneration.

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

Thanks for the pointer, I'll look into it.

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

Hm. This would actually be much more useful if it were to follow
the Visual Haskell method where hovering over a selection will
show you the type of the selected subexpression. Good ideas sprouting
again... pity it's almost bedtime. :)

Doei, Arthur.

-- 

   /\    / |       arthurvl at cs.uu.nl       | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody  
watching