hasktags - small patch

[Claus Reinke]

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

thanks for the pointer. it also seems to depend on rerunning ex-ctags
on a file every time a buffer on it is opened (possibly also when the file
changes on disk?). the faq says it won't use existing tags files generated
in any other way.

in view of that, perhaps ghc-api-based approaches won't combine well
with the existing plugin (speed/frequent reruns, incomplete projects, 
files in non-compilable state, ..). pity. perhaps one could take the
interface code from the plugin and combine it with a more ghc-friendly
backend. or it is back to quick&dirty pattern-based tag generators.

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

my vim fu is lacking, but not my wanting;-) i used to have a pattern-based
tag generator for my first non-trivial haskell project, but my coding styles
(and hence the patterns) keep changing. afaik, hasktags is just one of many
attempts to address the same problem -  i tried it, but found myself looking 
for more complete tag files. ghc-api based generators seemed to be the 
way to go, and embedding one into ghci made the task a lot easier.

since nobody seems to know what the best trade-off is between 
quick&flexible on one side and big&precise on the other, it is probably
a good thing to try several approaches. i was just worried that people 
might continue writing more hasktags style generators when their needs
might be met by one of the ghc-api-based ones. or that valuable time 
might be invested on sub-optimal routes. but as your explanation shows,
the ideal solution is not necessarily the best one, given context constraints.

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

yes, in principle. emacs even mixes the two styles (jump to position, then
search for the tag outwards, starting from there), though without proper
search patterns. in practice, the search patterns need to have enough context 
to distinguish, eg, class, type, module, but not enough context to be fooled 
by the kind of extensive refactoring/reordering/code cleaning that tends to 
accompany active haskell program development; also, incremental regeneration 
could be as fast as reloading one module into ghci.

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

should be possible these days. before vim had tooltips, i used the status
line to show hugs' :type output for the identifier under cursor, but i found
that so intrusive that i switched it off.

the interface between editor and haskell system is still a big question mark,
with various more or less non-portable approaches, but nothing really 
satisfying. for emacs, the subprocess idea almost works, for vim, dynamic
linking might be more direct, perhaps. problems, problems,..

> Good ideas sprouting again... pity it's almost bedtime. :)

hey, what is dreamtime good for, but to process and nurture good ideas:)

good luck with your experiments,
claus