better generation of vi ctags in ghci

[Claus Reinke]

> I got frustrated with vi tags not working after some unrelated code is 
> edited in a source file. Moreover non-exported top level declarations 
> were not available in vi tags file. Here is an attempt to fix it: 
> http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch

I'm all in favour of ctags improvements in general! Thanks for investing
the effort. Haven't looked at your patch in detail yet, just a few comments
based on your message:

> Why would you want the new implementation of :ctags ghci command?
> 
> * Tags are searched based on the line content. This is what Exuberant 
> Ctags do for other languages and it is the other posix way to do it. 
> This makes the positioning to work well even when the source code was 
> edited (on places unrelated to the tag location). More complicated Ex 
> statements can be used to improve it even more but then it does not work 
> well with :tselect (it screws up tag kinds, at least with my version of 
> vim 7.2.65).

Haskell isn't like other languages. If you search on source lines of
definitions, that'll break every time you change a pattern, parameter
name, parameter order, clause order, ..; if you search on less than the 
full line, you get additional misleading matches, especially because you
can only search forward or backward, not both (also, the fallback of
/^<tag>/ won't work for infix operators, classes, data, ..).

Ideally, one (well, I at least;-) would like a mixed approach: start with
source line, figure out if the line is right, if yes, done, if not, then search
(starting from the old position). But that seemed to be beyond posix 
tags, so I stuck with line numbers.

If the definition you're looking for isn't close to where it was, you'd
better regenerate the tags anyway; if the definition is still close, line
numbers degrade gracefully; search patterns tend to break completely
(on the other hand, line number changes affect more tags than definition
changes do, so it would be useful to have both options).

Note that emacs always does a search, but it does search outwards
in both directions, from the old location as the start position, so it can 
make do with an underspecified search pattern, such as the tag itself 
(if I recall correctly, the etags position might be off by one anyway; 
emacs doesn't have lines/columns, it counts bytes from the start or 
something like that, which meant that the etags and ctags parts couldn't
share all their code).

> * All top level symbols defined in a module are added to the tags file. 
> Even the non-exported ones. These are marked as static (file:) so the 
> default tag selection (Ctrl-]) works fine based on the file you started 
> the search from.

Thanks, I had meant to do this, don't know why I didn't (you use the new
static tag format, not the old, I assume?).
 
> * Tags get kinds added so you can select whether you want to get to a 
> type constructor or a data constructor (that is if you share names 
> between the two).

You mean 'kind' in the tags file sense, using it to record namespace, 
similar to haddock's t/v distinction?

The extended tag line format is somewhat underspecified (only file: and 
kind: are mentioned in Vim's docs), so I could not make up my mind
what to use kind: for (namespace? type? kind? type/data/class? package? 
..) and I couldn't figure out whether any editors would actually use the 
extra info if I were to add extra fields to add all the useful info.

In Vim, that info could be accessed via scripts, so it would be useful to 
add all of it, but some standard would help; also some of the info that 
:ctags could record in the tags file can be had by other means, including 
:type and :info output, and those other means will often be more up to 
date than the tags file, so I added no extra info to the tags file.
 
> * In general it is a nice addition to vim haskellmode. If you search for 
> help on symbols in libraries then opening haddock is cool. If you search 
> for help on a symbol in your project then opening the tag in a preview 
> window (Ctrl-W} or ptselect) is cool.

That's why I suggested the addition in the first place!-) Thanks for
taking it further. The one real show-stopper are files that GHCi can't
handle: because the ctags/etags patch borrowed all the interesting 
functionality from GHCi, it inherited its limitations as well (there is
a ghctags program somewhere which circumvents that issue by not
trying to generate code when generating tags, so it can handle tags
for GHC's sources, which GHCi :ctags couldn't, last time I tried). 
A secondary issue was what to do with non-interpreted modules
(probably: just skip, and rely on them having their own tags files).

(btw, I also use '_si' more since I switched it to open a preview window 
for the :info output, and of course, one can get the types without having 
to record them in the tags file).
 
> Problems:
> 
> * It needs somebody to check that emacs tags were not broken. I'm not an 
> emacs user but some tag generation code is shared for vim and emacs. I 
> tried to keep emacs tags exactly the way they were (only the exported 
> symbols, original file format).

I'm not an emacs user, either, I just added both versions because I saw
no reason not to (and I had been looking into the curious world of emacs 
terminology for other reasons). Simon M did quite a bit of cleanup on my
original patch, if I recall, perhaps other emacs users care to take a look?

> * If your code happens to have definitions on lines which happen to 
> exist more times in one source file then it may put you at an incorrect 
> location. I doubt it will ever happen but if anybody thinks it is really 
> bad we can keep the original format of vim tags too. Then e.g. :ctags 
> would generate tags with line numbers and :ctags! would generate tags 
> with search expressions.

See above for other things that can go wrong with search-based tags,
so I'd prefer to have both options.
 
Claus