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